I've answered a couple of questions about why Windows XP client does not
work with current NTPv4. Here is my stock reply.
The Windows XP client is broken in such an egregious way that I have
concluded this beyond simply not obeying the NTP specification, but an
attempt at product differentiation. I assume Microsoft's next move is to
offer a "compatible" server which only works with their client.
Ordinary clients are expected to send a client request (mode 3) and
receive a server response (mode 4), as it very clearly states in
rfc-1305 and rfc-2030. The XP client sends a symmetric active (mode 1}
request, which by specification invites the server to mobilize a
symmetric passive (mode 2) association. If this works, the XP client
would be considered a legitimate time source in itself, possibly
synchronizing the server in error and melting down the server and its
Because of the security risk, symmetric active clients must be
cryptographically authenticated in NTPv4. You can turn authentication
off by a "disable auth" command, but be advised the risk remains. Some
public servers, in particular time.nist.gov, have been modified so this
hazard does not exist. Other public servers who encounter an
unauthenticated mode 1 packet may well conclude this an attempted
security violation and report it to the security police. I look forward
to many such reports.
In spite of Microsoft's recto-cranial inversion, I have modified ntpd to
return a mode 2 packet when an unauthenticated mode 1 packet shows up,
but not to mobilize a passive association in that case. The Windows XP
client works and the hazard is avoided. The fix will be available in the
next update of the development repository.
Note that a packet with an invalid message authentication code returns a
crypto_NAK. You probably have never run across those things, but they
result in evil scoldings to the log and can result in a kiss-of-death
> In spite of Microsoft's recto-cranial inversion, I have modified ntpd to
> return a mode 2 packet when an unauthenticated mode 1 packet shows up,
> but not to mobilize a passive association in that case. The Windows XP
> client works and the hazard is avoided. The fix will be available in the
> next update of the development repository.
Why? Windows is bust, not NTP.
If it ain't broke, don't fix it.
Yes I know about minimizing "whine-age" (whinage?), but this is
simply embrace-and-extend on Microsoft's part. They did it with
Kerberos 5, and now with NTP.
David Magda <dmagda at ee.ryerson.ca>
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
I agree with your philosophy, but in fact the modified ntpd does conform
to the specification, if not the intent. "Be liberal in what you accept;
be generous to your enemies." (sorry Jon).