[ntp:questions] packet: pad header 020 / Leap not in sync

Martin Burnicki martin.burnicki at meinberg.de
Tue Sep 18 09:12:01 UTC 2007


Hi,

Folkert van Heusden wrote:
> Hi,
> 
> My ntpd won't sync.
> Situation:
> - windows 2003 server as ntp server
> - vmware esx 3.0.2 server as ntp client
> 
> When I run ntpdate -dq I get:
> 
> [root at somehost root]# ntpdate -dq 192.168.0.1
> 17 Sep 16:40:22 ntpdate[14661]: ntpdate 4.1.2 at 1.892 Tue Feb 24 06:32:26
> EST 2004 (1) transmit(192.168.0.1)
> receive(192.168.0.1)
> transmit(192.168.0.1)
> receive(192.168.0.1)
> transmit(192.168.0.1)
> receive(192.168.0.1)
> transmit(192.168.0.1)
> receive(192.168.0.1)
> transmit(192.168.0.1)
> 192.168.0.1: Server dropped: Leap not in sync
> server 192.168.0.1, port 123
> stratum 2, precision -6, leap 11, trust 000
> refid [193.67.79.202], delay 0.04144, dispersion 0.00578
> transmitted 4, in filter 4
> reference time:    ca98dfb8.5612472a  Mon, Sep 17 2007 13:12:56.336
> originate timestamp: ca99104d.1612472a  Mon, Sep 17 2007 16:40:13.086
> transmit timestamp:  ca991056.a9d5e4a3  Mon, Sep 17 2007 16:40:22.663
> filter delay:  0.04318  0.04926  0.04144  0.04681
>          0.00000  0.00000  0.00000  0.00000
> filter offset: -9.56796 -9.57296 -9.57709 -9.57998
>          0.000000 0.000000 0.000000 0.000000
> delay 0.04144, dispersion 0.00578
> offset -9.577090
> 
> 17 Sep 16:40:22 ntpdate[14661]: no server suitable for synchronization
> found

Yep, as displayed in the debug output the leap bit are set to "11" which
means the server is not synchronized, so a real NTP client won't accept it.

> Also when I run: ntpd -g -d I get:
> 
> [root at somehost root]# ntpd -g -d
> ntpd 4.1.2 at 1.892 Tue Feb 24 06:32:25 EST 2004 (1)
> create_sockets(123)
> interface <lo> OK
> interface <vswif0> OK
> bind() fd 4, family 2, port 123, addr 0.0.0.0, flags=1
> bind() fd 5, family 2, port 123, addr 127.0.0.1, flags=0
> bind() fd 6, family 2, port 123, addr 192.168.0.2, flags=1
> init_io: maxactivefd 6
> peer_clear: at 0 assoc ID 0
> newpeer: 192.168.0.2->192.168.0.1 mode 3 vers 4 poll 6 10 flags 201 1 ttl
> 0 key 00000000 peer_clear: at 0 assoc ID 0
> newpeer: 127.0.0.1->127.127.1.0 mode 3 vers 4 poll 6 6 flags 21 1 ttl 0
> key 00000000 report_event: system event 'event_restart' (0x01) status
> 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) auth_agekeys: at
> 1 keys 1 expired 0 transmit: at 5 192.168.0.2->192.168.0.1 mode 3
> receive: at 5 192.168.0.2<-192.168.0.1 mode 4 code 1
> packet: bad header 020
> refclock_transmit: at 10 127.127.1.0
> refclock_receive: at 10 127.127.1.0
> peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event,
> event_reach' (0x8014) refclock_sample: n 1 offset 0.000000 disp 0.010000
> jitter 0.000000 clock_filter: n 1 off 0.000000 del 0.000000 dsp 7.937508
> jit 0.000008, age 0 transmit: at 20 192.168.0.2->192.168.0.1 mode 3
> receive: at 20 192.168.0.2<-192.168.0.1 mode 4 code 1
> packet: bad header 020
> 
> What would be the cause?

A short grep over the source code indicates this are the "flash" bits, and
the comment for 0x20 says:
#define TEST6           0x0020  /* peer clock unsynchronized */

So this is the same problem: the server does not claim to be synchronized.

> ntpd version on esx is:
> 
> [root at somehost root]# ntpd --version
> ntpd: ntpd 4.1.2 at 1.892 Tue Feb 24 06:32:25 EST 2004 (1)
> 
> ntp version on the windows server:
> [root at somehost root]# ntpq -c ntpversion -version 192.168.0.1
> NTP version being claimed is 2

AFAIK the above is just the version of the protocol ntpq uses when sending
queries to the server, see the documentation for ntpq.

> ntpq 4.1.2 at 1.892 Tue Feb 24 06:32:31 EST 2004 (1)

Overall I'd say you should find out why your server does not claim to be
synchronized.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list