[ntp:questions] Re: Servers reachable, but can't sync

Danny Mayer mayer at gis.net
Sun Sep 11 02:24:03 UTC 2005


Greg McCann wrote:
> Sorry for the top-posting, but I wanted to insert some relevant information that I discovered while answering your questions below.
> 
> In the tcpdump analysis of the ntpdate communication in my previous post (and thanks to some of your hints), I noticed that ntpdate was communicating with the server through an unprivileged port (33347) when sucessfully using the -q option, but was using the ntp port (123) when unsucessfully using the -b option.
> 
> I then noticed in the ntpdate documentation...
> 
> -u      Direct ntpdate to use an unprivileged port for outgoing packets.
> 
> So I tried...
> 
> # ntpdate -ub 65.200.108.234
> 8 Sep 10:43:25 ntpdate[20450]: step time server 65.200.108.234 offset 1.472721 sec
> 
> # ntpdate -ub 65.200.108.234
> 8 Sep 10:43:43 ntpdate[20452]: step time server 65.200.108.234 offset 0.000169 sec
> 
> There is no error message, and it appears that the clock has been sucessfully adjusted.  It looks like we are getting somewhere.  I am mystified though, as to why there would be any communication trouble on port 123, when tcpdump appears to show port 123 communication completing successfully in both directions.  Other machines on the same network are able to sync with the same server with no problems.
> 
> The only difference I can think of in the network configuration for this machine is that while most machines on the network are connected to switched ports, the machine where I am having trouble is connected to an unswitched port, since it is being used as a network sniffer.  (Though I have disabled the sniffer while running these tests to avoid further complications.)
> 
> I tried to find an option to get ntpd to use an unprivileged port, but there doesn't seem to be one.
> 

ntpd definitely will ONLY use port 123 for both outgoing and incoming
NTP packets. Don't even look to change it.

> I guess the only thing left is to figure out what the problem is with port 123, though I can't think of any reason it would be blocked, and tcpdump seems to show packets coming and going through port 123 just the same as they are on an unprivileged port.
> 

90% of all problems like this are firewalls, the other 10% are due to
restrict lines in the configuration file.

Danny
> 
> Greg




More information about the questions mailing list