Windows won't Sync to NTP server - NTP

This is a discussion on Windows won't Sync to NTP server - NTP ; I can't get a Windows Client to sync to my NTP server. All Linux clients work fine. Here is the info from my ntp.conf: driftfile /var/lib/ntp/drift restrict 127.0.0.1 restrict mask 255.255.224.0 nomodify notrap server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Windows won't Sync to NTP server

  1. Windows won't Sync to NTP server

    I can't get a Windows Client to sync to my NTP server. All Linux
    clients work fine.

    Here is the info from my ntp.conf:

    driftfile /var/lib/ntp/drift
    restrict 127.0.0.1
    restrict mask 255.255.224.0 nomodify notrap
    server 0.rhel.pool.ntp.org iburst
    server 1.rhel.pool.ntp.org iburst
    server 2.rhel.pool.ntp.org iburst


    Here is the tcpdump and ntpd -d info:

    TCP DUMP OUTPUT:

    13:02:19.440054 IP .ntp > .ntp: NTPv3, symmetric
    active, length 48


    ntpd -d output

    receive: at 447 cent.ntp<-winclient mode 1 code 5 auth 0
    transmit: at 447 cent.ntp->winclient mode 1

    My NTP version is: ntp-4.2.4p2-1.fc6

    IPTables is off for testing

    Any suggestions?

    Thanks

  2. Re: Windows won't Sync to NTP server

    lind.fedora@gmail.com wrote:
    > I can't get a Windows Client to sync to my NTP server. All Linux
    > clients work fine.


    You didn't say that you were running a non-NTP compliant version of
    w32time on the Windows system (it's illegally using symmetric active).

    It is possible that your version of ntpd does not have the workaround
    for the w32time bug that was extensively discussed last week. You
    should try setting the options on w32time that causes it to generate
    proper client associations, upgrading to Windows 2003 (which is reported
    to be compliant). Alternatively, you could run the reference ntpd on the
    Windows systems.


    >
    > TCP DUMP OUTPUT:
    >
    > 13:02:19.440054 IP .ntp > .ntp: NTPv3, symmetric
    > active, length 48


    Version 3 and symmetric active are part of the w32time signature.
    >
    >
    > ntpd -d output
    >
    > receive: at 447 cent.ntp<-winclient mode 1 code 5 auth 0
    > transmit: at 447 cent.ntp->winclient mode 1


    It does look like it is w32time tolerant. As it has logged the
    transmit, it seems unlikely that the problem is in ntpd.
    >
    > My NTP version is: ntp-4.2.4p2-1.fc6


    That has vendo9 version suffixes. You may need to get support from the
    vendor.


  3. Re: Windows won't Sync to NTP server

    On Mar 28, 1:15*pm, lind.fed...@gmail.com wrote:
    > I can't get a Windows Client to sync to my NTP server. *All Linux
    > clients work fine.


    What Windows client version (and service pack level) are you using?
    Are the machines a member of an Active Directory domain?

    It's quite possible your settings for w32time arfe being overridden by
    Windows Time policies configured on your Windows domain controllers.

    And of course there are potentially client firewall issues on the
    Windows machines. Can you do a:

    w32tm /monitor /computers:X.X.X.X

    on the Windows machine where X.X.X.X is the IP of your time server? If
    that works, then the problem is not network related, but probably a
    policy issue.

  4. Re: Windows won't Sync to NTP server

    David Woolley wrote:
    > lind.fedora@gmail.com wrote:
    >> I can't get a Windows Client to sync to my NTP server. All Linux
    >> clients work fine.

    >
    > You didn't say that you were running a non-NTP compliant version of
    > w32time on the Windows system (it's illegally using symmetric active).
    >
    > It is possible that your version of ntpd does not have the workaround
    > for the w32time bug that was extensively discussed last week. You
    > should try setting the options on w32time that causes it to generate
    > proper client associations, upgrading to Windows 2003 (which is reported
    > to be compliant). Alternatively, you could run the reference ntpd on the
    > Windows systems.


    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.

    Danny

  5. Re: Windows won't Sync to NTP server

    On Mar 30, 10:03*pm, ma...@ntp.isc.org (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 mask 255.255.252.0 nomodify notrap
    restrict 127.0.0.1

    My ntpd version for my pool server is 4.2.4p4@1.1520-modena-o
    (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



  6. Re: Windows won't Sync to NTP server

    On Mar 31, 10:30 am, Ryan Malayter wrote:
    > On Mar 30, 10:03 pm, ma...@ntp.isc.org (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 mask 255.255.252.0 nomodify notrap
    > restrict 127.0.0.1
    >
    > My ntpd version for my pool server is 4.2....@1.1520-modena-o
    > (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

  7. Re: Windows won't Sync to NTP server

    On Mar 31, 1:43 pm, mlind wrote:
    > On Mar 31, 10:30 am, Ryan Malayter wrote:
    >
    >
    >
    > > On Mar 30, 10:03 pm, ma...@ntp.isc.org (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 mask 255.255.252.0 nomodify notrap
    > > restrict 127.0.0.1

    >
    > > My ntpd version for my pool server is 4.2....@1.1520-modena-o
    > > (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


    Tried the following at this link:

    http://www.meinberg.de/english/faq/faq_28.htm

    With the 0x8 appended to the end I can see the Windows Client coming
    in at Mode 3 Code 3 Auth 0, the same as the Linux Clients. Wireshark
    on the Windows Client reveals the following information:

    Flags: 0xdb
    11.. .... = Leap Indicator: alarm condition (clock not
    synchronized) (3)
    ..01 1... = Version number: NTP Version 3 (3)
    .... .011 = Mode: client (3)

    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Polling Interval: 5 (32 sec)
    Peer Clock Precision: 0.015625
    Root Delay: 0.0000 sec
    Root Dispersion: 1.0156 sec
    Reference Clock ID: NULL
    Reference Clock Update Time: NULL
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: Mar 31, 2008 19:11:07.4531 UTC


    Here is the Wireshark from a Linux Client that is getting time for
    reference:

    Flags: 0xe3
    11.. .... = Leap Indicator: alarm condition (clock not
    synchronized) (3)
    ..10 0... = Version number: NTP Version 4 (4)
    .... .011 = Mode: client (3)
    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Polling Interval: 4 (16 sec)
    Peer Clock Precision: 0.015625 sec
    Root Delay: 1.0000 sec
    Root Dispersion: 1.0000 sec
    Reference Clock ID: NULL
    Reference Clock Update Time: NULL
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: Mar 31, 2008 19:15:24.3356 UTC

    Thanks again

  8. Re: Windows won't Sync to NTP server

    On Mar 31, 2:20*pm, mlind wrote:

    > With the 0x8 appended to the end I can see the Windows Client coming
    > in at Mode 3 Code 3 Auth 0, the same as the Linux Clients. *Wireshark
    > on the Windows Client reveals the following information:


    So you just get no replies at all to the Windows machines? And they
    are on the same subnet, with the same firewall and router
    configurations as the "working" linux clients?

    Very strange indeed, especially since the packet traces indicate the
    Windows and Linux machines are sending almost

    You didn't mention if the machines were part of an Active Directory
    domain or not, nor what version they were. w32time should report its
    source selection or any errors in the System event viewer. Are there
    any entries there on one of hte Windows clients? If so, can you post
    the details?

  9. Re: Windows won't Sync to NTP server


    >> > ***** 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

    ....


    >> > ***** 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

    ....

    How long are the packets? Both the ones that work and the ones
    that don't work.

    NTP has some optional authentication stuff that gets appended to
    the standard packet. There is some discussion on another list
    about MS inventing their own incompatible authentication.

    If the packets that don't work are longer than normal, that's
    probably what is going on.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  10. Re: Windows won't Sync to NTP server

    Danny,

    Danny Mayer wrote:
    > David Woolley wrote:
    > ntp 4.2.4p4 does not include that fix nor do any of the tarballs for
    > ntp-dev yet. That fix is coming.


    The fix *is* already there. It has been introduced in ntp v4.1.73, and is
    still in the current ntp-stable version, i.e. 4.2.4p4.

    If a "symmetric active" (mode 1) request is sent to ntpd v4.2.4p4 then the
    daemon also replies with a mode 1 response.

    Dave has (unintentionally ?) removed that workaround in ntp-dev, and he has
    re-added it recently. However, AFAIK, the re-added fix has not made its way
    into the ntp-dev repo, or any tarballs.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  11. Re: Windows won't Sync to NTP server

    On Apr 1, 5:01 am, Martin Burnicki
    wrote:
    > Danny,
    >
    > Danny Mayer wrote:
    > > David Woolley wrote:
    > > ntp 4.2.4p4 does not include that fix nor do any of the tarballs for
    > > ntp-dev yet. That fix is coming.

    >
    > The fix *is* already there. It has been introduced in ntp v4.1.73, and is
    > still in the current ntp-stable version, i.e. 4.2.4p4.
    >
    > If a "symmetric active" (mode 1) request is sent to ntpd v4.2.4p4 then the
    > daemon also replies with a mode 1 response.
    >
    > Dave has (unintentionally ?) removed that workaround in ntp-dev, and he has
    > re-added it recently. However, AFAIK, the re-added fix has not made its way
    > into the ntp-dev repo, or any tarballs.
    >
    > Martin
    > --
    > Martin Burnicki
    >
    > Meinberg Funkuhren
    > Bad Pyrmont
    > Germany


    Windows Clients are not domain machines. Length is 48 bytes for both
    Linux and Windows Clients.

    According to the Event viewer the NTP server is "unreachable" even
    though I run:

    w32tm /monitor /computers:

    And get:

    ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
    NTP: -229.9545908 offset from local clock
    RefID: ntp.logicx.net [64.25.87.54]

    I know that the ICMP should be blocked per the FW in between my
    Windows Client and the NTP server.

    Thanks again

  12. Re: Windows won't Sync to NTP server

    On Apr 1, 8:20 am, mlind wrote:
    > On Apr 1, 5:01 am, Martin Burnicki
    > wrote:
    >
    >
    >
    > > Danny,

    >
    > > Danny Mayer wrote:
    > > > David Woolley wrote:
    > > > ntp 4.2.4p4 does not include that fix nor do any of the tarballs for
    > > > ntp-dev yet. That fix is coming.

    >
    > > The fix *is* already there. It has been introduced in ntp v4.1.73, and is
    > > still in the current ntp-stable version, i.e. 4.2.4p4.

    >
    > > If a "symmetric active" (mode 1) request is sent to ntpd v4.2.4p4 then the
    > > daemon also replies with a mode 1 response.

    >
    > > Dave has (unintentionally ?) removed that workaround in ntp-dev, and he has
    > > re-added it recently. However, AFAIK, the re-added fix has not made its way
    > > into the ntp-dev repo, or any tarballs.

    >
    > > Martin
    > > --
    > > Martin Burnicki

    >
    > > Meinberg Funkuhren
    > > Bad Pyrmont
    > > Germany

    >
    > Windows Clients are not domain machines. Length is 48 bytes for both
    > Linux and Windows Clients.
    >
    > According to the Event viewer the NTP server is "unreachable" even
    > though I run:
    >
    > w32tm /monitor /computers:
    >
    > And get:
    >
    > ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
    > NTP: -229.9545908 offset from local clock
    > RefID: ntp.logicx.net [64.25.87.54]
    >
    > I know that the ICMP should be blocked per the FW in between my
    > Windows Client and the NTP server.
    >
    > Thanks again


    On Apr 1, 8:20 am, mlind wrote:
    > On Apr 1, 5:01 am, Martin Burnicki
    > wrote:
    >
    >
    >
    > > Danny,

    >
    > > Danny Mayer wrote:
    > > > David Woolley wrote:
    > > > ntp 4.2.4p4 does not include that fix nor do any of the tarballs for
    > > > ntp-dev yet. That fix is coming.

    >
    > > The fix *is* already there. It has been introduced in ntp v4.1.73, and is
    > > still in the current ntp-stable version, i.e. 4.2.4p4.

    >
    > > If a "symmetric active" (mode 1) request is sent to ntpd v4.2.4p4 then the
    > > daemon also replies with a mode 1 response.

    >
    > > Dave has (unintentionally ?) removed that workaround in ntp-dev, and he has
    > > re-added it recently. However, AFAIK, the re-added fix has not made its way
    > > into the ntp-dev repo, or any tarballs.

    >
    > > Martin
    > > --
    > > Martin Burnicki

    >
    > > Meinberg Funkuhren
    > > Bad Pyrmont
    > > Germany

    >
    > Windows Clients are not domain machines. Length is 48 bytes for both
    > Linux and Windows Clients.
    >
    > According to the Event viewer the NTP server is "unreachable" even
    > though I run:
    >
    > w32tm /monitor /computers:
    >
    > And get:
    >
    > ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
    > NTP: -229.9545908 offset from local clock
    > RefID: ntp.logicx.net [64.25.87.54]
    >
    > I know that the ICMP should be blocked per the FW in between my
    > Windows Client and the NTP server.
    >
    > Thanks again


    I have now tried this:

    NTP VERSION (From CENTOS):

    ntp-4.2.2p1-7.el5

    NTP CONFIG:

    restrict 127.0.0.1
    restrict -6 ::1
    server 0.fedora.pool.ntp.org iburst
    server 1.fedora.pool.ntp.org iburst
    server 2.fedora.pool.ntp.org iburst
    driftfile /var/lib/ntp/drift


    Again nothing has changed. Both 0x1 modes and 0x8 modes do not work.
    Also the "w32tm..." command I tried above gets similar results.

    I am at a real loss here....

    Thanks again for all your help

  13. Re: Windows won't Sync to NTP server

    On Apr 1, 9:57 am, mlind wrote:
    > On Apr 1, 8:20 am, mlind wrote:
    >
    >
    >
    > > On Apr 1, 5:01 am, Martin Burnicki
    > > wrote:

    >
    > > > Danny,

    >
    > > > Danny Mayer wrote:
    > > > > David Woolley wrote:
    > > > > ntp 4.2.4p4 does not include that fix nor do any of the tarballs for
    > > > > ntp-dev yet. That fix is coming.

    >
    > > > The fix *is* already there. It has been introduced in ntp v4.1.73, and is
    > > > still in the current ntp-stable version, i.e. 4.2.4p4.

    >
    > > > If a "symmetric active" (mode 1) request is sent to ntpd v4.2.4p4 then the
    > > > daemon also replies with a mode 1 response.

    >
    > > > Dave has (unintentionally ?) removed that workaround in ntp-dev, and he has
    > > > re-added it recently. However, AFAIK, the re-added fix has not made its way
    > > > into the ntp-dev repo, or any tarballs.

    >
    > > > Martin
    > > > --
    > > > Martin Burnicki

    >
    > > > Meinberg Funkuhren
    > > > Bad Pyrmont
    > > > Germany

    >
    > > Windows Clients are not domain machines. Length is 48 bytes for both
    > > Linux and Windows Clients.

    >
    > > According to the Event viewer the NTP server is "unreachable" even
    > > though I run:

    >
    > > w32tm /monitor /computers:

    >
    > > And get:

    >
    > > ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
    > > NTP: -229.9545908 offset from local clock
    > > RefID: ntp.logicx.net [64.25.87.54]

    >
    > > I know that the ICMP should be blocked per the FW in between my
    > > Windows Client and the NTP server.

    >
    > > Thanks again

    >
    > On Apr 1, 8:20 am, mlind wrote:
    >
    >
    >
    > > On Apr 1, 5:01 am, Martin Burnicki
    > > wrote:

    >
    > > > Danny,

    >
    > > > Danny Mayer wrote:
    > > > > David Woolley wrote:
    > > > > ntp 4.2.4p4 does not include that fix nor do any of the tarballs for
    > > > > ntp-dev yet. That fix is coming.

    >
    > > > The fix *is* already there. It has been introduced in ntp v4.1.73, and is
    > > > still in the current ntp-stable version, i.e. 4.2.4p4.

    >
    > > > If a "symmetric active" (mode 1) request is sent to ntpd v4.2.4p4 then the
    > > > daemon also replies with a mode 1 response.

    >
    > > > Dave has (unintentionally ?) removed that workaround in ntp-dev, and he has
    > > > re-added it recently. However, AFAIK, the re-added fix has not made its way
    > > > into the ntp-dev repo, or any tarballs.

    >
    > > > Martin
    > > > --
    > > > Martin Burnicki

    >
    > > > Meinberg Funkuhren
    > > > Bad Pyrmont
    > > > Germany

    >
    > > Windows Clients are not domain machines. Length is 48 bytes for both
    > > Linux and Windows Clients.

    >
    > > According to the Event viewer the NTP server is "unreachable" even
    > > though I run:

    >
    > > w32tm /monitor /computers:

    >
    > > And get:

    >
    > > ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
    > > NTP: -229.9545908 offset from local clock
    > > RefID: ntp.logicx.net [64.25.87.54]

    >
    > > I know that the ICMP should be blocked per the FW in between my
    > > Windows Client and the NTP server.

    >
    > > Thanks again

    >
    > I have now tried this:
    >
    > NTP VERSION (From CENTOS):
    >
    > ntp-4.2.2p1-7.el5
    >
    > NTP CONFIG:
    >
    > restrict 127.0.0.1
    > restrict -6 ::1
    > server 0.fedora.pool.ntp.org iburst
    > server 1.fedora.pool.ntp.org iburst
    > server 2.fedora.pool.ntp.org iburst
    > driftfile /var/lib/ntp/drift
    >
    > Again nothing has changed. Both 0x1 modes and 0x8 modes do not work.
    > Also the "w32tm..." command I tried above gets similar results.
    >
    > I am at a real loss here....
    >
    > Thanks again for all your help


    Hey guys. Turns out it's not my config or NTP at all.

    Long story short the NTP server is in a DMZ. The other IT department
    opened up for NTP to and from their client network. Linux clients got
    the time through, and as you all well know Windows clients did not.

    Today I finally could get access to their DMZ and I put a Windows
    Client in it. Boom, like magic it was all set. Even coming in as
    mode 1. I asked to see the log of the firewall and turns out they
    didn't have logging on for that port. I asked them to turn logging
    on. I will report back in a few days.

    Thanks again for all your help.

+ Reply to Thread