[ntp:questions] Re: 4.2.0 at 1.1161-r | Server dropped: strata too high | How to change this

Danny Mayer mayer at gis.net
Wed Feb 4 20:40:11 UTC 2004


google at nicolinux.de (Stefan Nicolin) wrote in message news:<c5f87ac9.0402040626.138ce31d at posting.google.com>...
> Hi,
> 
> with ntpd I have the said error every time I try to sync time from a
> unix client. How can the server get syncronized? That's the complete
> output from "ntpdate -d 192.168.0.2"
> 
> ---
>  4 Feb 14:36:31 ntpdate[1758]: ntpdate 4.1.2 at 1.892 Tue Feb  3 12:28:16
> CET 2004
> (1)
> transmit(192.168.0.2)
> receive(192.168.0.2)
> transmit(192.168.0.2)
> receive(192.168.0.2)
> transmit(192.168.0.2)
> receive(192.168.0.2)
> transmit(192.168.0.2)
> receive(192.168.0.2)
> transmit(192.168.0.2)
> 192.168.0.2: Server dropped: strata too high
> server 192.168.0.2, port 123
> stratum 16, precision -20, leap 11, trust 000
> refid [73.78.73.84], delay 0.02571, dispersion 0.00000
> transmitted 4, in filter 4
> reference time:    00000000.00000000  Thu, Feb  7 2036  7:28:16.000

I'd be concerned where this date came from! That's 32 years into the future.
It's too far off to be valid. Check out that server at 192.168.0.2.


> originate timestamp: c3cb73c4.1ded288c  Wed, Feb  4 2004 14:36:04.116
> transmit timestamp:  c3cb73df.656e1587  Wed, Feb  4 2004 14:36:31.396
> filter delay:  0.02577  0.02571  0.02571  0.02573 
>          0.00000  0.00000  0.00000  0.00000 
> filter offset: -27.2793 -27.2793 -27.2793 -27.2793
>          0.000000 0.000000 0.000000 0.000000
> delay 0.02571, dispersion 0.00000
> offset -27.279369
> 
>  4 Feb 14:36:31 ntpdate[1758]: no server suitable for synchronization
> found
> ---
> 
> According to the detailed informations "leap 11" the ntpd server
> claims itself that it is not syncronized. That's my question - how to
> get the server syncronized? And yes it was running for more than one
> day (before) :)
> 
> On the server side it is a simple setup - Here is the ntpd.conf:
> 
> ---
> server 195.13.23.5
> server 129.240.64.3
> server 212.42.1.207
> 
> restrict default noserve        # default deny
> restrict 127.0.0.1              # allow local host
> restrict 192.168.0.0 mask 255.255.255.0 nopeer nomodify notrap
> restrict 192.168.1.0 mask 255.255.255.0 nopeer nomodify notrap
> 
> driftfile /etc/ntp.drift
> ---
> 
> It seems that the server does not syncronise itself for whatever
> reason. Port 123 (udp) is allreade open (outbound, keep state).
> 
> Doing a ntptrace on the first server from the config reveals this:
> 
> ---
> 195.13.23.5: stratum 2, offset 0.045841, root distance 0.162429
> ---
> 
> Upon starting the ntpd server with the -d switch - this is the output:
> 
> ---
> addto_syslog: logging to file /var/log/ntpd.log
> ntpd 4.2.0 at 1.1161-r Tue Feb  3 11:41:03 CET 2004 (1)
> addto_syslog: logging to file /var/log/ntpd.log
> 
> addto_syslog: ntpd 4.2.0 at 1.1161-r Tue Feb  3 11:41:03 CET 2004 (1)
> 
> addto_syslog: signal_no_reset: signal 13 had flags 4000000
> 
> addto_syslog: precision = 1.000 usec
> 
> create_sockets(123)
> root at modula:~# addto_syslog: no IPv6 interfaces found
> bind() fd 3, family 2, port 123, addr 0.0.0.0, flags=8
> bind() fd 6, family 2, port 123, addr 127.0.0.1, flags=0
> bind() fd 7, family 2, port 123, addr 192.168.0.2, flags=8
> init_io: maxactivefd 7
> local_clock: at 0 state 0
> key_expire: at 0
> peer_clear: at 0 assoc ID 4380 refid INIT
> newpeer: 192.168.0.2->195.13.23.5 mode 3 vers 4 poll 6 10 flags 0x1
> 0x1 ttl 0 key 00000000
> key_expire: at 0
> peer_clear: at 0 assoc ID 4381 refid INIT
> newpeer: 192.168.0.2->129.240.64.3 mode 3 vers 4 poll 6 10 flags 0x1
> 0x1 ttl 0 key 00000000
> key_expire: at 0
> peer_clear: at 0 assoc ID 4382 refid INIT
> newpeer: 192.168.0.2->212.42.1.207 mode 3 vers 4 poll 6 10 flags 0x1
> 0x1 ttl 0 key 00000000
> addto_syslog: frequency initialized 0.000 PPM from /etc/ntp.drift
> 
> local_clock: at 0 state 1
> report_event: system event 'event_restart' (0x01) status 'sync_alarm,
> sync_unspec, 1 event, event_unspec' (0xc010)
> transmit: at 1 192.168.0.2->195.13.23.5 mode 3
> auth_agekeys: at 1 keys 1 expired 0
> timer: refresh ts 0
> transmit: at 2 192.168.0.2->129.240.64.3 mode 3
> transmit: at 3 192.168.0.2->212.42.1.207 mode 3
> ---
> 
> Thanks much
> 
> Stefan

If the date's too far off it won't reset itself without forcing it. Try using
the -g flag.

Danny



More information about the questions mailing list