Re: Windows Time with NTPv4



Ryan Malayter wrote:
On Mar 13, 3:56 am, Martin Burnicki <martin.burni...@xxxxxxxxxxx>
wrote:
The default was that ntpd just dropped those requests, i.e. didn't send a
response at all, in which case the w32time clients were unable to
synchronize to the NTP server, unless they were reconfigured correctly to
send "client" requests.

Hmm... I've notice lots of Windows machines that connect to my pool
server, which runs ntpd 4.2.4p4@xxxxxxxxxxxx (Meinberg). Wireshark
indicates that the ntp srever does reply with Symmetric Active packets
to thse Windows clients (mode 1), even though no peers or
authentication are configured. I even have a "restrict default nopeer"
in there.

(I say "Windows clients" as I am guessing anything that is NTPv3,
clock precision of -6, and requests symmetric active is a Windows
client.)

I've also never had any trouble syncing to any pool.ntp.org servers
using w32time, even without the 0x8 client mode identifier.

Hm, I actually had just a very quick look on the NTP code changes where this
kind of packets is handled (search vor "case AM_NEWPASS:" in ntp_proto.c).

As I've already mentioned in an earlier post the original workaround was
introduced in v4.1.73, dated around 2002-08-04, which was a -dev version
before the next stable version 4.2.0.

Also as already mentioned, that piece of code modified around March/April
2005, but it looks like the workaround has not been removed but only
changed.

I've got a little program here which can send request packets to an NTP
server and display the contents of both the request and reply packet. I've
run that program against different Linux machines here running different
NTP versions:

Before the original workaround ntpd did not reply at all to unauthenticated
mode 1 requests:

ntpd 4.0.99f Sat Jul 29 13:00:13 GMT 2000 (1)
mode 3 req -> mode 4 resp
mode 1 req -> timeout

With the original workaround it sends a mode 2 response:

ntpd 4.2.0a@xxxxxxxx Sat Mar 19 19:20:10 UTC 2005 (1)
mode 3 req -> mode 4 resp
mode 1 req -> mode 2 resp

With the modified workaround as in current ntp-stable it sends a mode 1
response:

ntpd 4.2.4p3@xxxxxxxx Fri Sep 21 21:36:25 UTC 2007 (1)
mode 3 req -> mode 4 resp
mode 1 req -> mode 1 resp

And finally the current ntp-dev version again does not reply at all to
unauthenticated mode 1 requests:

ntpd 4.2.5p113@xxxxxxxx Thu Mar 13 16:03:23 UTC 2008 (1)
mode 3 req -> mode 4 resp
mode 1 req -> timeout

So, Dave, the older workaround has been removed after the 4.2.4 release.
Please note that your latest patch which introduced the workaround again is
not yet available in the BK repos or an ntp-dev tarball.

Ryan, that should also explain why we havn't heard much in the last years
about w32time clients not sync'ing to NTP servers.


Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany
.



Relevant Pages

  • Re: NTP daemon - fixed offset against real time
    ... I need to setup one ntp server to serve its sntp clients ... bugs if theprogram running TV stuff added on the offset. ...
    (comp.protocols.time.ntp)
  • Re: NTP stratum problem
    ... We have solris stations with ntp 4.2, act as a server and clients. ... Vxworks machines polling these Solaris clients using VxWorks ...
    (comp.protocols.time.ntp)
  • Re: broadcast client
    ... I have a question regarding broadcast mode. ... synchronizing with the same ntp server. ... ntp displined clock. ... I notice that two clients have a relatively large offset ...
    (comp.protocols.time.ntp)
  • Re: NTP Server Setup
    ... to this NTP server for updates. ... where it may be preferable to stay with w32time rather than to install NTP. ... If the server is a domain controller and the clients (also running w32time, ...
    (comp.protocols.time.ntp)
  • RE: Users Cant Access Documents on Server
    ... Thanks for using the SBS newsgroup. ... As well as we know, if a workstation would not access network shares, then ... Leave the Default Gateway of the internal NIC blank of the server box. ... Clients That Require SMB Signing ...
    (microsoft.public.windows.server.sbs)