[ntp:questions] Windows Time with NTPv4

David L. Mills mills at udel.edu
Fri Mar 14 00:00:06 UTC 2008


Remember, enable/disable auth has nothing to do with authentication 
itself, just whether new associations can be mobilized if no 
authentication is used. In your case a symmetric passive association was 
apparently mobilized and began sending mode-2 packets just as if a 
legitimate peer was involved.

Windows was apparently happy with the reply, even if it was up to 64 
seconds delayed, and apparently successfully ignored subsequent mode-2 
packets sent from the association until it timed out.

These are probably unintended consequences, so disable auth is probably 
not an optimum workaround. Better to use the Windows workaround. I have 
included a link to the Microsoft KB in the latest documentation and will 
provide some way to selectively activate the workaround mentioned 


Evandro Menezes wrote:
> On Mar 13, 3:56 am, Martin Burnicki <martin.burni... at meinberg.de>
> wrote:
>>Do the Windows system run ntpd or w32time? If they run ntpd then
>>authentication could be configured correctly. I don't know how any version
>>of w32time could be configured to support NTP's symmetric keys or even
> They run w32time.
>>This seems to indicate that ntpd is running on the XP machines and has been
>>configured correctly with authentication.
> Actually not.  I had this in ntp.conf:
> restrict default kod limited nopeer
> tos orphan 4
> enable bclient
> disable auth
> Then, the w32time systems appeared as servers in the output of "ntpq -
> p" and "ntpdc -c listpeers" confirmed their status as peers.
> When I removed the last line above, as w32time doesn't support
> authentication keys, the w32time systems stopped showing up as
> servers, even though their association mode remained 1.  So w32time
> was happy, believing it was a peer (if it indeed behaves as a peer is
> left to be demonstrated), and NTP kept on working without the
> interference of w32time in its choice of servers.
>>Of course the admin of a NTP server does not want his NTP server's time be
>>changed just because some dumb client sends some packet asking to do so.
> But I think that with the proper restrictions NTP will do the right
> thing.
>>This is what happens with w32time which under certain conditions sends
>>"peer" requests instead of "client" requests. Since those w32time clients
>>have neither been configured nor authenticated as peers, the question is
>>how they should be handled by ntpd.
> I think that they're being handled just fine by NTP.  NTP does what
> ntp.conf tells it to do and it can handle w32time stupidity just fine
> as in my case above.
> Thanks.

More information about the questions mailing list