[ntp:questions] ntp client running on windows not syncing ntp server running on windows

Martin Burnicki martin.burnicki at burnicki.net
Tue Nov 22 10:39:08 UTC 2016


Hi,

sneha b wrote:
> Hi,
> 
> I am using ntp.4.2.8, compiled the source code from ntp.org and using the
> same.
> But when I try to run ntpd.exe the client is not syncing with server, if I
> change time in client and run ntpd.exe -q I see some KoD packets received
> at client side.

Why are you running "ntpd -q"? This tries to set the time and then ntpd
stops itself. If this is intended then eventually you should at least
add the parameter "-g" so that initial large offsets (more than ~1000 s)
are also accepted, i.e. "ntpd -gq".

See more replies inline below.

> Below is the message I am seeing:
> 
> C:\Windows\SysWOW64>ntpd.exe -q
> 22 Nov 14:18:47 ntpd[40932]: ntp-keygen 4.2.8p8 at 1.3265-o Oct 28 12:19:56.86
> (UTC+05:0-30) 2016  (1): Starting
> 22 Nov 14:18:47 ntpd[40932]: Command line: ntpd.exe -q
> 22 Nov 14:18:47 ntpd[40932]: Raised to realtime priority class
> 22 Nov 14:18:47 ntpd[40932]: Clock interrupt period 15.625 msec
> 22 Nov 14:18:47 ntpd[40932]: Performance counter frequency 2.604 MHz
> 22 Nov 14:18:47 ntpd[40932]: Windows clock precision 0.977 msec, min. slew
> 6.400 ppm/s
> 22 Nov 14:18:47 ntpd[40932]: using Windows clock directly
> 22 Nov 14:18:47 ntpd[40932]: proto: precision = 976.500 usec (-10)
> 22 Nov 14:18:47 ntpd[40932]: proto: fuzz beneath 0.174 usec
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 11
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 12
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 13
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 14
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 15
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 16
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 17
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 18
> 22 Nov 14:18:47 ntpd[40932]: authreadkeys: invalid type for key 19

The messages above clearly state that something is wrong with your keys,
so if you try to use authentication with those keys it will probably
never work.

> 22 Nov 14:18:47 ntpd[40932]: Listen and drop on 0 v6wildcard [::]:123
> 22 Nov 14:18:47 ntpd[40932]: Listen and drop on 1 v4wildcard 0.0.0.0:123
> 22 Nov 14:18:47 ntpd[40932]: Listen normally on 2 Internal network
> 165.100.10.1:123
> 22 Nov 14:18:47 ntpd[40932]: Listen normally on 3 DICOM network
> 3.204.31.137:123
> 22 Nov 14:18:47 ntpd[40932]: Listen normally on 4 Loopback Pseudo-Interface
> 1 [::1]:123
> 22 Nov 14:18:47 ntpd[40932]: Listen normally on 5 Loopback Pseudo-Interface
> 1 127.0.0.1:123
> 22 Nov 14:18:47 ntpd[40932]: receive: KoD packet from 3.204.31.138 has
> inconsistent xmt/org/rec timestamps.  Ignoring.
> 22 Nov 14:19:51 ntpd[40932]: receive: KoD packet from 3.204.31.138 has
> inconsistent xmt/org/rec timestamps.  Ignoring.
> 22 Nov 14:20:56 ntpd[40932]: receive: KoD packet from 3.204.31.138 has
> inconsistent xmt/org/rec timestamps.  Ignoring.
> 22 Nov 14:22:03 ntpd[40932]: receive: KoD packet from 3.204.31.138 has
> inconsistent xmt/org/rec timestamps.  Ignoring.
> 22 Nov 14:23:10 ntpd[40932]: ntservice: The Network Time Protocol Service
> is stopping.
> 
> Client has ntp.conf with below details:
> 
> peer 127.127.1.0

Why are you using the local clock driver "127.127.1.0" with the "peer"
command? I'm not sure this works at all. I'm also not sure you need the
local clock driver at all on the client. maybe you should remove the
line "peer 127.127.1.0".

> server 3.204.31.138 prefer key 1

As said above, you should first try without the "key 1" parameter and
see if this works.

Why do you think you need "prefer" here? I't probably not what you
expected. Maybe you should use a line like this first:

server 3.204.31.138 iburst minpoll 6 maxpoll 6

and append "key 1" if you are sure the line above works.

I've recently explained here
https://groups.google.com/d/msg/comp.protocols.time.ntp/6vgScpf3pmA/BBu_M8S4AQAJ

why you should use minpoll/maxpoll, specifically if you're running
windows 7.

> keys <path to keys file>
> trustedkey 1
> tinker step 0
> 
> server has below in ntp.conf
> peer 127.127.1.0

Same here. Why "peer 127.127.1.0"? If you need it you should try

server 127.127.1.0

> server 165.100.10.1

The line above should be

server 165.100.10.1 iburst minpoll 6 maxpoll 6

if it's your own server, or

server 165.100.10.1 iburst minpoll 6 maxpoll 7

if it's not your own server.

> keys <path to keys file>
> trustedkey 1 2 3 4 5
> tinker step 0
> 
> Environment windows7 for client and server
> 
> I am struck here, as I am unable to go further, in wireshark capture I am
> seeing the NTP packets being exchanged between client and server.

With the configuration you've shown in your email the NTP server would
not send kiss-of-death packets at all, so I bet you have in addition
some "restrict" lines on the server (and also on the client?) which
prevent from proper operation.

Martin



More information about the questions mailing list