aphro <[EMAIL PROTECTED]> wrote:
>just make sure xntp3 is running, you can test it by telnetting to
>port 37 on the ntp server
Yes, a telnet to .1 37 does indeed return a little healty garbage -
although I thought perhaps ntp connects to port 123 using udp (this
idea based on a 'grep ntp /etc/services' and the assumption it sends
udp packets in the name of speed - perhaps my conception has been
off?)
Jean-Yves BARBIER <[EMAIL PROTECTED]> wrote:
>That means your xntpd is not loaded, otherwise it should return:
> 2 Nov 03:21:51 ntpdate[5563]: the NTP socket is in use, exiting
Yes, I do indeed get this message ntpd is running on .2 (I notice that
I am not running xntpd and hope that isn't the issue; my ntp
installation comes from package version 4.0.98a-1 and seems to run a
binary /usr/sbin/ntpd). In the name of troubleshooting, my thought
was to kill ntpd (/etc/init.d/ntp stop) on .2 and use ntpdate from
there to test if the ntp server on .1 was working.
Here is some verbose, debugging from running ntpdate on .2 (after I've
stopped ntpd on .2 to free the socket):
--
> ntpdate -v -d 192.168.1.1
1 Nov 21:50:21 ntpdate[529]: ntpdate 4.0.98a Sun Sep 19 16:24:58 MDT 1999 (1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
server 192.168.1.1, port 123
stratum 16, precision -17, leap 11, trust 000
refid [0.0.0.0], delay 0.02573, dispersion 0.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Wed, Feb 6 2036 22:28:16.000
originate timestamp: bbc8fa1d.c5360d02 Mon, Nov 1 1999 21:50:21.770
transmit timestamp: bbc8fa1d.4c75e636 Mon, Nov 1 1999 21:50:21.298
filter delay: 0.02579 0.02573 0.02573 0.02573
0.00000 0.00000 0.00000 0.00000
filter offset: 0.471602 0.471602 0.471601 0.471602
0.000000 0.000000 0.000000 0.000000
delay 0.02573, dispersion 0.00000
offset 0.471602
1 Nov 21:50:21 ntpdate[529]: no server suitable for synchronization found
--
>From this it seems clear that .2 can communicate with ntpd on .1 (If I
stop ntpd on .1 the output for the same command looks assuringly
different, e.g. no receive(192.168.1.1) lines and lots of zero values
for stuff like timestamp, delay).
>From my perspective, the problem to appears to be in the line:
stratum 16, precision -17, leap 11, trust 000
It's like ntpdate doesn't consider .1 'suitable' or trustworthy to
sync up with. Maybe I need to find a way to bump up .1's advertised
stratum?
Meantime, thanks for the tips - at least netdate 192.168.1.1 works, so
I could band-aid a cron-job to periodically run netdate...
/Iain Lamb
