On Sunday, January 1, 2006 at 4:06:14 +0000, Danny Mayer wrote: > Serge Bets wrote: >> why IFF would succeed with a client symlink, and TC would succeed >> without? Outside of the 20051002 change? > IFF works fine without a client symlink.
In my case, without a client symlink on the 20051225 ntp-dev client, IFF is not selected, IFF key is not loaded, there is no IFF bit in default flags, no IFF bit in cryptostats flags, and no IFF bit in association flags. The server is authenticated via TC scheme, becomes reachable, and will work very well like that. Same setup, but with an additional client symlink ntpkey_iff_Client, pointing to ntpkey_IFFkey_Server.3340702253, or alternatively with an additional "crypto ident iff" statement: IFF works fine. Clients are Windows or Linux, with daemon version 20051002 or more recent (tested up to 20051225). Server platform and daemon version seemingly don't count. It is fully repeatable. Thanks to an old hint from you Danny, I removed a typo letter from ntp_proto.c and became able to compile 20051002 on Woody. Check confirms Linux is touched, and snapshot 20051002 is the initial version. So far I do not see anything that could explain such TC/IFF discrepency, out of the 20051002 change. > I have no idea what a strict client setup is. In this thread context, Steve and me have agreed to use the "strict client" expression for: - An ntpd that is configured only as a client member of a trust group and does not serve authenticated time to others. Configured exactly as per ConfiguringAutokey section 6.6.2. More precisely a strict client has an untrusted cert, and an IFFkey ntpkey_IFFkey_Server.3340702253 file imported from Server, with an ntpkey_iff_Server symlink pointing to it. Essentially it has not any IFFpar at all. Serge. -- Serge point Bets arobase laposte point net _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
