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

sneha b snehabadardinni at gmail.com
Wed Nov 23 04:32:02 UTC 2016


Thanks Martin will try with whatever options provided by you.

Thanks,
Sneha

On Tue, Nov 22, 2016 at 11:39 AM, Martin Burnicki <
martin.burnicki at burnicki.net> wrote:

> 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
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>


More information about the questions mailing list