Re: Windows won't Sync to NTP server

On Mar 31, 10:30 am, Ryan Malayter <malay...@xxxxxxxxx> wrote:
On Mar 30, 10:03 pm, ma...@xxxxxxxxxxx (Danny Mayer) wrote:

ntp 4.2.4p4 does not include that fix nor do any of the tarballs for
ntp-dev yet. That fix is coming. Martin Burnicki or Ryan Malayter
provided instructions on how to get w32time to send client packet
instead of symmetric active packets. The clients are getting synched
because the restrict statement is denying peers.

Are you sure about that? It seems like that "windows hack" code is
already in there.

My pool NTP server is sending out symmetric-active replies to Windows
clients, even though I have these restrict statements:
restrict default kod limited nomodify notrap nopeer
restrict <internal subnet> mask 255.255.252.0 nomodify notrap
restrict 127.0.0.1

My ntpd version for my pool server is 4.2....@xxxxxxxxxxxxxxx
(distributed by Meinberg).

Below is a packet trace from Wireshark, that illustrates the request-
response cycle from what I believe is a Windows user of pool.ntp.org:

***** Request Packet *******
Internet Protocol, Src: 68.152.80.170 (68.152.80.170), Dst:
38.98.155.10 (38.98.155.10)
User Datagram Protocol, Src Port: 62096 (62096), Dst Port: ntp (123)
Network Time Protocol
Flags: 0x19
00.. .... = Leap Indicator: no warning (0)
..01 1... = Version number: NTP Version 3 (3)
.... .001 = Mode: symmetric active (1)
Peer Clock Stratum: secondary reference (3)
Peer Polling Interval: 10 (1024 sec)
Peer Clock Precision: 0.015625 sec
Root Delay: 0.0329 sec
Root Dispersion: 7.8348 sec
Reference Clock ID: 66.199.242.154
Reference Clock Update Time: Mar 31, 2008 13:52:17.9219 UTC
Originate Time Stamp: Mar 31, 2008 13:52:01.9721 UTC
Receive Time Stamp: Mar 31, 2008 13:52:02.0000 UTC
Transmit Time Stamp: Mar 31, 2008 14:09:05.9786 UTC

***** Reply packet **********
Internet Protocol, Src: 38.98.155.10 (38.98.155.10), Dst:
68.152.80.170 (68.152.80.170)
User Datagram Protocol, Src Port: ntp (123), Dst Port: 62096 (62096)
Network Time Protocol
Flags: 0x19
00.. .... = Leap Indicator: no warning (0)
..01 1... = Version number: NTP Version 3 (3)
.... .001 = Mode: symmetric active (1)
Peer Clock Stratum: secondary reference (2)
Peer Polling Interval: 10 (1024 sec)
Peer Clock Precision: 0.000001 sec
Root Delay: 0.0394 sec
Root Dispersion: 0.0068 sec
Reference Clock ID: 192.77.171.2
Reference Clock Update Time: Mar 31, 2008 14:08:21.9166 UTC
Originate Time Stamp: Mar 31, 2008 14:09:05.9786 UTC
Receive Time Stamp: Mar 31, 2008 14:09:05.9858 UTC
Transmit Time Stamp: Mar 31, 2008 14:09:05.9859 UTC

The funny thing is that I have another server with the same ntp
version, same configuration and it works for Windows Clients. They
even come in the same way. I am really stumped as to why one works
and the other doesn't.

Also I need two because I work in an organization with multiple IT
departments. The one that isn't working is for the other department.
All of which have little to no Unix/Linux exp which is what we run a
good portion of our Internet Based servers on. They are learning but
when these issues arise they fall to me and my staff.

Thanks again
.

Relevant Pages

  • Re: Windows wont Sync to NTP server
    ... Peer Clock Stratum: secondary reference ... Reference Clock Update Time: Mar 31, 2008 13:52:17.9219 UTC ... Originate Time Stamp: Mar 31, ...
    (comp.protocols.time.ntp)
  • Clarification on the org, rec, xmt header fields
    ... Peer Clock Stratum: secondary reference ... Reference Clock Update Time: May 16, 2009 05:20:49.8112 UTC ... Originate Time Stamp: May 16, ...
    (comp.protocols.time.ntp)
  • Re: Kiss-O-Death
    ... Did you also check the source port number of the request packets? ... Time Source Destination Protocol Info ... Peer Clock Stratum: unspecified or unavailable ... Originate Time Stamp: NULL ...
    (comp.protocols.time.ntp)
  • Re: Windows wont Sync to NTP server
    ... Peer Clock Stratum: secondary reference ... Reference Clock Update Time: Mar 31, ... Originate Time Stamp: Mar 31, ... With the 0x8 appended to the end I can see the Windows Client coming ...
    (comp.protocols.time.ntp)
  • Re: Time Zones (Was: IBMLink is UP - just kidding)
    ... between UTC and the then-current local time. ... the 'SET TIME or SET TIMEZONE' commands could be issued on different LPARs with different values every few seconds to change the local date/time to values that are essentially unpredictable. ... There are no conversions except to use the current local date/time offset and leap seconds values to derive the local date/time from UTC when first storing a time stamp. ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
    (bit.listserv.ibm-main)