On 11/07/2005 04:24 AM, Bjørge Solli wrote:
<snip>
I *am* behind NAT if that matters.
Can you try to sniff the comunication. (tcpdump / ethereal) That way it may be possible to see if the request is actually made.
pia:~ # tcpdump|grep rasmus tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:23:06.863883 IP pia.ntp > rasmus.uib.no.ntp: NTPv4 client, strat 0, poll 4, prec -6
(more of the same) Your NTP packets are getting out, but no replies are coming in. I have not checked this server in the list of public access servers maintained at ntp.isc.org, but it would appear from posts by others there should be no problem just connecting to them. If you installed the xntp-doc package, there is an FAQ in /usr/share/doc/packages/xntp-doc/NTP-FAQ, specifically for this problem the file NTP-s-trouble.htm -- but for the benefit of anyone who did not install that package, your problem is usually associated with a firewall or packet filter that is not open for UDP on the ntp port. It is important to note that by default, the ntp protocol uses UDP port 123 for both source and destination ports. Wherever your NAT is happening (your internet provider perhaps?), probably they are blocking inbound traffic on privileged ports (those below 1024). Try ntpdate with the -u option to force it to select an unprivileged port as the source (you could use the -d "debug" option instead, to see more information on exactly what is happening). If that works, then my suspicion is likely correct. The downside of this is that the ntpd daemon does not seem to have the same option -- unless I missed something somewhere in the documentation, it always uses port 123 for both source and destination. If your internet provider has closed UDP port 123 for inbound traffic, you could always send them an email asking them to open it. Even if you wanted to operate ntpd in server mode, it isn't going to generate as much traffic as a web or ftp server, so I do not think such a request is unreasonable. It is even possible they did not even think to open any privileged UDP ports -- the ntp documentation even suggests this is a common failing of network administrators. If you cannot get the port opened by whoever closed it, then you still have a couple of options available: 1) there is a very good alternative to xntp, called "chrony", that I used under SuSE 6.3 and 7.2. It now works with more recent kernels (it didn't work with kernel 2.4 when I upgraded to SuSE 9.0, which is why I stopped using it), see http://chrony.sunsite.dk for details. It has separate server and client programs, but does not support any hardware reference clocks (such as a radio receiver clock or GPS receiver). So unless you have a GPS receiver connected to your system, you can try chrony (but then you don't need an external NTP server anyway :) ). In client mode, you can set the source port to something other than 123 as a config file option. Chrony uses what seems to be a very good linear regression routine to determine the current system clock corrections, which is why I like it. 2) set up ntpdate to run as a cron task in the root crontab, with the -u option of course. Once an hour should keep your clock reasonably accurate, unless your computer runs extremely fast or slow (an error of 100 parts per million equals a clock error of 0.36 seconds per hour). If so, the uncorrected system clock frequency can be calculated manually, and set at boot time (for example, using ntptime, also part of the xntp package), or you can simply run the cron task more frequently.