Error getting samples from external NTP source



In a network with 6 WS2K3 Enterprise DCs (single domain/forest) I configured
one of them (the Operations Master) as an NTP client for an external reliable
NTP reference (a radio clock). The W32Time log file (with EventLogFlags=3)
reports that the WinServer2003 reaches the external NTP, gets an NTP packet
response but then ignores it. The error messages logged are: "Packet test 2
failed (response does not match request)" and then "Ignoring packet invalid
mode combination (in:2 out:4)".
I tried either setting NtpServer Type as "NTP" or "AllSync". The above
occurs in "AllSync" mode ("NTP" was even worse).
What that error message mean ? Where I could find some documentation or tip ?
(KB was unuseful).
Here follows the exact log trace. 10.1.2.1 is the reliable NTP source.
Thanks in advance for any help.

Sergio

147679 22:15:05.1395000s - ListeningThread -- response heard from 10.1.2.1:123
147679 22:15:05.1395000s - /-- NTP Packet:
147679 22:15:05.1395000s - | LeapIndicator: 0 - no warning; VersionNumber:
3; Mode: 2 - SymmetricPassive; LiVnMode: 0x1A
147679 22:15:05.1395000s - | Stratum: 1 - primary reference (syncd by radio
clock)
147679 22:15:05.1395000s - | Poll Interval: 15 - out of valid range;
Precision: -8 - 3.90625ms per tick
147679 22:15:05.1395000s - | RootDelay: 0x0000.0000s - unspecified;
RootDispersion: 0x0000.0000s - unspecified
147679 22:15:05.1395000s - | ReferenceClockIdentifier: 0x47505300 - source
name: "GPS"
147679 22:15:05.1395000s - | ReferenceTimestamp: 0xC62124E7FEFAA877147679
22:15:05.1395000s - - 12759545703996012200ns - 147679 22:15:03.9960122s
147679 22:15:05.1395000s - | OriginateTimestamp: 0xC62124E7FEFAA877147679
22:15:05.1395000s - - 12759545703996012200ns - 147679 22:15:03.9960122s
147679 22:15:05.1395000s - | ReceiveTimestamp: 0xC62124E7FEFAA877147679
22:15:05.1395000s - - 12759545703996012200ns - 147679 22:15:03.9960122s
147679 22:15:05.1395000s - | TransmitTimestamp: 0xC62124E7FEFAA877147679
22:15:05.1395000s - - 12759545703996012200ns - 147679 22:15:03.9960122s
147679 22:15:05.1395000s - >-- Non-packet info:
147679 22:15:05.1395000s - | DestinationTimestamp: 147679 22:15:05.1395000s
- 0xC62124E923B645A1147679 22:15:05.1395000s - -
12759545705139500000ns147679 22:15:05.1395000s - - 147679 22:15:05.1395000s
147679 22:15:05.1395000s - | RoundtripDelay: 1143487800ns (1s)
147679 22:15:05.1395000s - | LocalClockOffset: -571743900ns - 0:00.571743900s
147679 22:15:05.1395000s - \--
147679 22:15:05.1395000s - Peer 10.1.2.1
(ntp.m|0x0|10.1.4.13:123->10.1.2.1:123) is not Win2K. Setting compat flags.
147679 22:15:05.1395000s - Packet test 2 failed (response does not match
request).
147679 22:15:05.1395000s - Ignoring packet that failed tests from 10.1.2.1
(ntp.m|0x0|10.1.4.13:123->10.1.2.1:123).

.



Relevant Pages

  • Re: servers address in ntp payload?
    ... >> with all the stateful firewalls now in place if the response to a packet ... >> the address and the requestor will never receive a response. ... > Which is a flaw in such a firewall and a violation of RFC 2979. ... appears to only discuss TCP and it's layered protocols which NTP isn't. ...
    (comp.protocols.time.ntp)
  • Re: Very rapid polling
    ... Authorised Server every 300ms on our LAN. ... sending this same packet every 300-500ms. ... Does the ntp process submit these packets repeatedly or ... see from the packet analyser that it is expects a response back. ...
    (comp.protocols.time.ntp)
  • Re: Time between sending and receiving of Ethernet Packet
    ... receiving of packet from one application to another one. ... Also i am having "Ethereal" tool to see when packet leaving one ... You send data to the other application which sends a response ... NTP can be a good solution but is there any possibility of getting this ...
    (comp.unix.programmer)
  • BlueGiga W11 Integration
    ... device 0032ce78] packet 0x0032bd10 op 0c03 ... response ...
    (microsoft.public.windowsce.platbuilder)
  • Re: 1394 Async Request Rx (BUSY_X blocking)
    ... I am not getting speed above 70 Mbps in async because of response ... through Microsoft driver) to avoid write response. ... > packet is received. ... From its DPC the driver calls a routine that parses the ...
    (microsoft.public.development.device.drivers)