I'm having trouble synchronising the time of my network clients using NTP. I have a server (helios.perrings) running NTP and listening on UDP 123 (confirmed usinf lsof -i). I also have configured the clients to request time from this server. However, the clients report that no time server can be found. From the documentation, it appears that the src port and dest port should both be 123, but when I do a tcpdump, I get the following results:
20:58:27.476153 IP 192.168.0.10.32851 > helios.perrings.ntp: NTPv4 client, strat 0, poll 4, prec -6 20:58:27.476927 IP helios.perrings.ntp > 192.168.0.10.32851: NTPv4 server, strat 0, poll 4, prec -18
The client's (192.168.0.10) return address is 32851, not 123 as expected.
I've been trying to find where this alternative port is set, but going round in circles. Any ideas, suggestions, please?
Stuart.
On Tue, Aug 17, 2004 at 10:01:44AM +0100, Stuart Bailey wrote:
I'm having trouble synchronising the time of my network clients using NTP. I have a server (helios.perrings) running NTP and listening on UDP 123
Which distribution?
It all works fine for me with Debian Woody and Sarge (ntpd v4.1.0-ish) but the manual does warn that by default ntpd exits if the offset exceeds 1000s. Might not be relevent to your problem, though.
From the documentation, it appears that the src port and dest port should both be 123,
Really? "man ntpd" doesn't mention the port number at all.
I hope we can help - NTP is great!
Tim.
Stuart Bailey wrote:
I'm having trouble synchronising the time of my network clients using NTP. I have a server (helios.perrings) running NTP and listening on UDP 123 (confirmed usinf lsof -i). I also have configured the clients to request time from this server. However, the clients report that no time server can be found.
[snip port discussion]
I had a problem that sounds similar to yours and it turned out that I hadn't configured the server to allow the clients to connect. This showed up as the clients reporting no time server found.
JD
On Tue, 2004-08-17 at 10:01, Stuart Bailey wrote:
I'm having trouble synchronising the time of my network clients using NTP.
Stuart and I investigated this a bit more today.
However, the clients report that no time server can be found.
That was because the configured server wasn't synchronized -- that makes the server "stratum 16", and clients refuse to sync with that.
The reason that the server wasn't synchronized was that it never received responses to the packets it sent. Often that's due to the host firewall, the router firewall, or ISP port restrictions. But in this case it was because the dlink dsl300t adsl modem drops packets with Minimize-Delay IP_TOS set. http://www.magwag.plus.com/jim/tips-300t.html
With that fixed the server and clients now sync properly.
Random tips for others debugging ntp issues: - running ntpd in the foreground ("ntpd -u ntp:ntp -g -n -d -d") makes it easier to see what it's getting/sending - running tcpdump shows you what makes it out to the network - run "tcp-wait" to see if/when your server syncs - run "ntpq -c rv" to see the stratum of your server - check your ntp.conf file -- if you have something like "restrict default noquery notrust nomodify", then you need to explicitly reset the restriction for the upstream server you use, e.g. "restrict ntp.eclipse.co.uk noquery", otherwise ntpd will ignore the responses to the queries it sends out.
-- Martijn
On Wed, 2004-08-18 at 22:56, Martijn Koster wrote:
The reason that the server wasn't synchronized was that it never received responses to the packets it sent. Often that's due to the host firewall, the router firewall, or ISP port restrictions. But in this case it was because the dlink dsl300t adsl modem drops packets with Minimize-Delay IP_TOS set. http://www.magwag.plus.com/jim/tips-300t.html
With that fixed the server and clients now sync properly.
I ended up with the Dlink 300T, and it took far too much time to get traffic for a block 8 IP's to route through it. However the main problem was that after upgrading the firmware it wouldn't install a default route.
I ended up writing a python script which telnets on to the router (via cron) to check things like the firewall are disabled, mtu is set correctly, and the correct routes/arp are statically configured.
The weather that we are having around Ipswich means every couple of weeks there modem resets due to brief power outages. I wanted the modem to be useful again even if I wasn't physically able to attend it. http://172.20.0.13/mycrap/dlinksucks/dlink-300t.tar.bz2
-
Jon Dye -
Martijn Koster -
Mr. Adam ALLEN -
Stuart Bailey -
Tim Green