[SOLVED] NTP Problem

tronayne · 05-07-2014, 09:50 AM

Although WilliamS is not using a router (he has a direct Ethernet connection to his modem -- which may be a modem or it may be a modem/router such as what HughesNet provides to me and many cable providers do the same thing, it's a modem/router, not just a modem).

In my installation, I have HughesNet with an Ethernet connection from the satellite box to a Linksys BEFSR41 router. I also have a Netgear Wireless N150 Access Point router connected to the Linksys to provide wireless support for my wife's Kindle (and, every so often, my lap top which is usually connected via Ethernet). All my systems are connected via Ethernet, one of them provides NTP time to all the others. In the Linksys set up menu, specifically what they call Applications & Gaming, there is a Port Range page where I pass HTTP (port 80 to 80 TCP), SSHD (port 22 to 22 Both) and NTPD (port 123 to 123 UDP); if this is not done, there's no HTTP, no SSHD and no NTPD services available from the outside world (such as NTP).

I don't use the Netgear for anything but wireless for the Kindle and when my daughter visits (she is constantly whacking away at some damned device or other using the wireless), so it is not set up to pass ports.

I've "fixed" a few installations for friends that could not access NTP though their router by simply editing the port range (the /etc/service file in Slackware comes with NTP enabled so there's no fiddling with that -- used to be that other systems did not have NTP enabled and you had to either add or uncomment the NTP lines in <path_to>/services).'

I've been using NTP since the late 80's or early 90's (don't remember exactly) and never have had it not work. You used to need to find at least one, preferable two or three stratum 2 servers to synchronize with (and ask if it was OK to use one of those, just to be polite); there was no "pool" of available time servers and you did not want to synchronize with a stratum 1 server without explicit permission to do so (you still don't do that). Early on, it was xntp, now ntpd, but the results, at least for me, have been set up ntp.conf, get the system clock within about a minute of real time, start 'er up and there you go.

One problem was that you needed stratum 2 services electrically close to you. From a list of public servers, you'd ping and pick the ones with the with the shortest time values. And those buggers would be up, down, noisy, clean or all screwed up and NTP did a real good job of switching from one to the other when one went down. Nowadays you'll synchronize with stratum 2, 3, 4 or more and that's not a problem because NTP will evaluate the servers, throw out "bad" servers and add new ones from the pool to keep things going. It's pretty slick.

The reason that the fudge server lines are in /etc/ntp.conf (as explained in the comments right above that server block ) is that when you lose your Internet connection NTP will fall back on the local clock (your system clock) until the Internet comes back. Same thing if all the pool servers you have specified are too far out of useable range, NTP will throw out the existing pool and get new pool servers until it finds one that's acceptable. It could not do that with hard-coded stratum 2 servers, it can with the pool servers.

I've been thinking about popping $300 for a GPS network time server (just 'cause I like having toys) but I really can't justify that given that NTP does the job and I'm connected to the Internet 24/7. It's just me and that doesn't make much sense but...

If you're keeping a server farm on time, you can probably justify one or two GPS time servers (redundancy matters: what if somebody pulls the plug?).

A large manufacturer I used to consult for did have a WWV time server for the production line computer systems (and pretty much everything else). The room it was in was being painted and the painters pulled the plug to paint around the outlet then plugged it back in. The damned thing reset to the epoch date (it just happened to be the Unix epoch date) over the weekend and guess what happened to every computer. Lots of fannies and elbows adjusting data bases and line computers and who knows what-all before that mess got cleaned up.

That sort of stuff doesn't happen with NTP (and, of course the manufacturer of the WWV timer server got the message about backing the thing up with a 9-volt battery). Couple of million dollars worth of screwed up records, labor and, oh, by the way, shutting down production for about 12 hours. Not a Good Thing.

Bottom line, though, is that NTP does work and it works well. If it doesn't, there's a reason and, in more than a few cases that I'm personally familiar with, it was simply turning on the port in a router, couple of minutes, all done. Of course finding that out took a little longer, lesson learned during a wasted youth.

Hope this helps some.

michaelk · 05-07-2014, 10:08 AM

Another option to the standalone time server is just buying a GPS receiver assuming you have or want to run a box 24/7. I have a Garmin 18X serial port device but there are many others. They cost $85 USD direct from Garmin but you might be able to get them cheaper else where. For accurate time it has a 1 PPS output signal. And yes it is a toy...

interndan · 05-07-2014, 06:58 PM

I have been using the following method to keep my clock accurate for nearly as long as I have been running Slackware.

First I always select hardware clock set to local time on every new installation. (I know that isn't the recommended practice).

After the installation is finished and updates ran using slackpkg, I create a file called settime in /etc/cron.daily. Use terminal logged in as root.

Code:

pico /etc/cron.daily/settime

paste the following in the new file

Code:

usr/sbin/ntpdate north-america.pool.ntp.org && /sbin/hwclock -w

Change the time server to your choice, save the file.

Make the new file executable.

Code:

chmod +x /etc/cron.daily

After the file is created and made executable, issue the following (still as root)

Code:

/etc/cron.daily/settime

When that is completed your computer will update the time every day. If your machine has been off for a while you can always issue the command manually. My clocks are always correct.

One discalaimer, I did not create this, I found it years ago doing a search for how to keep clocks accurate in Slackware.

interndan · 05-07-2014, 07:00 PM

A quick addition to the above, I have never need the ntp daemon running with this method.

Richard Cranium · 05-07-2014, 09:22 PM

On the other hand, I've used ntpd to keep the clocks accurate on my home network ever since I've had a 24/7 internet connection (which is at least 10 years).

The ntp protocol is old, robust, and as fully tested as any such protocol can be. If your machine can actually use the ntp protocol to talk to servers in the ntp pool, your clocks will remain accurate. There are at least hundreds of thousands of servers that use ntpd to keep their clocks accurate. If your server cannot use ntpd to keep its clock on time but is connected to the internet 24/7, there is something odd about your access to the internet. Which is essentially the same thing that tronayne wrote a couple of posts earlier.

eloi · 05-08-2014, 06:44 AM

Quote:

Originally Posted by WilliamS

I had the opposite experience, such that ntp always worked perfectly.
All I did was comment out the fudge lines, put the pool servers into /etc/ntp.conf and chmod +x the two rc.d scripts.

So you're giving me the same treatment your ISP gave to you. ;-)

I wasn't accurate calling ntpd "problematic" because the issues I experienced were at boot time; ntpd failing in the first attempt because a internet connection issue. Not nptd fault. Obviously that wouldn't happen in a 24/7 server. That's why some people (and distributions by default) prefer the ntpdate-cron solution in desktop machines you power off every day.

Even so, there are scenarios were ntpd could fail (i.e. FreeBSD jails) that could not mean a ntpd problem, but the problem is still there. I don't find really useful the "I've never had problems" even coming from guys with a long time experience.

WilliamS · 05-09-2014, 10:55 AM

"We had our level three technicians take a look at it, and the port is not blocked."
That is the word from the ISP.

So I did the below checks, and ntp still does not work, and I have no idea of what to do next.
Any advice welcome.

Code:

# ntpq -pn 
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 67.215.197.151  .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 192.95.20.208   .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 24.87.64.125    .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 208.81.1.197    .INIT.          16 u    - 1024    0    0.000    0.000   0.000
bash-4.2# ntpdate -u 0.ca.pool.ntp.org
 9 May 11:42:31 ntpdate[4871]: step time server 67.213.74.13 offset -3.312180 sec
bash-4.2# ntpdate 0.ca.pool.ntp.org
 9 May 11:43:01 ntpdate[4885]: the NTP socket is in use, exiting
bash-4.2# /etc/rc.d/rc.ntpd stop
Stopping NTP daemon...
bash-4.2# ntpdate -u 0.ca.pool.ntp.org
 9 May 11:44:17 ntpdate[4903]: adjust time server 24.87.64.125 offset 0.001243 sec
bash-4.2# ntpdate 0.ca.pool.ntp.org
 9 May 11:45:08 ntpdate[4916]: no server suitable for synchronization found
bash-4.2# /etc/rc.d/rc.ntpd start
Starting NTP daemon:  /usr/sbin/ntpd -g
Saving system time to the hardware clock (localtime).
bash-4.2# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 142.165.36.190  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 198.50.145.138  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 198.50.168.37   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 206.186.121.118 .INIT.          16 u    -   64    0    0.000    0.000   0.000
bash-4.2# ntpq -pn 0.ca.pool.ntp.org
72.51.27.50: timed out, nothing received
***Request timed out

interndan · 05-09-2014, 09:19 PM

Try leaving the leading [ 0.] off your selected server.

Code:

ntpdate -u ca.pool.ntp.org

FirstHorseman · 05-10-2014, 04:14 AM

I'm having the same issue with NTP on Slackware 14.1 64-bit. Did some monitoring with tcpdump and verfied that udp 123 is not being blocked. The funny thing is that KDE will "automatically" update the time, but if I try to use the ntp daemon, nothing.

Here is a copy of my ntp.conf:

Code:

# Sample /etc/ntp.conf:  Configuration file for ntpd.
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
#server 127.127.1.0     # local clock
#fudge  127.127.1.0 stratum 10

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org



#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
                                                                                                                          
#                                                                                                                         
# Uncomment to use a multicast NTP server on the local subnet:                                                            
#multicastclient 224.0.1.1              # listen on default 224.0.1.1                                                     
# Set an optional compensation for broadcast packet delay:                                                                
#broadcastdelay 0.008

#
# Keys file.  If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will.
#
#keys           /etc/ntp/keys
#trustedkey     65535
#requestkey     65535
#controlkey     65535

#
# Don't serve time or stats to anyone else by default (more secure)
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

#
# Disable the ntpdc -c monlist command, which is insecure and can be used
# to cause a denial of service attack (CVE-2013-5211). Future versions of
# NTP will remove this command.
disable monitor

#
# Trust ourselves.  :-)
restrict 127.0.0.1
restrict ::1

... and here is the output from ntpq -p and ntpq > as:

Code:

root@Slackware:/etc/rc.d# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ec2-54-209-65-1 .INIT.          16 u    -   64    0    0.000    0.000   0.000
 paladin.latt.ne .INIT.          16 u    -   64    0    0.000    0.000   0.000
 orchid.sidereal .INIT.          16 u    -   64    0    0.000    0.000   0.000
root@Slackware:/etc/rc.d# ntpq
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 58254  8011   yes    no  none    reject    mobilize  1
  2 58255  8011   yes    no  none    reject    mobilize  1
  3 58256  8011   yes    no  none    reject    mobilize  1
ntpq>

tcpdump shows zero traffic when trying to use ntpd or ntpdate (with daemon off):

Code:

root@Slackware:/etc/rc.d# tcpdump udp port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes

However... if I stop ntpd and have KDE set the time "automatically" (see attachment), when I click "Apply" I immediately start getting udp 123 traffic in my tcpdump:

Code:

root@Slackware:/etc/rc.d# tcpdump udp port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
02:06:38.693143 IP 192.168.1.6.ntp > fairy.mattnordhoff.net.ntp: NTPv4, Client, length 48
02:06:38.770028 IP fairy.mattnordhoff.net.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:38.893091 IP 192.168.1.6.ntp > 74.117.238.11.rdns.continuumdatacenters.com.ntp: NTPv4, Client, length 48
02:06:38.979928 IP 74.117.238.11.rdns.continuumdatacenters.com.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:39.093096 IP 192.168.1.6.ntp > perturb.org.ntp: NTPv4, Client, length 48
02:06:39.155763 IP perturb.org.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:39.293115 IP 192.168.1.6.ntp > blackhole.jetta.net.ntp: NTPv4, Client, length 48
02:06:40.693104 IP 192.168.1.6.ntp > fairy.mattnordhoff.net.ntp: NTPv4, Client, length 48
02:06:40.764577 IP fairy.mattnordhoff.net.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:40.893120 IP 192.168.1.6.ntp > 74.117.238.11.rdns.continuumdatacenters.com.ntp: NTPv4, Client, length 48
02:06:40.976045 IP 74.117.238.11.rdns.continuumdatacenters.com.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:41.093111 IP 192.168.1.6.ntp > perturb.org.ntp: NTPv4, Client, length 48
02:06:41.154764 IP perturb.org.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:41.293130 IP 192.168.1.6.ntp > blackhole.jetta.net.ntp: NTPv4, Client, length 48
02:06:42.693116 IP 192.168.1.6.ntp > fairy.mattnordhoff.net.ntp: NTPv4, Client, length 48
02:06:42.762702 IP fairy.mattnordhoff.net.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:42.893083 IP 192.168.1.6.ntp > 74.117.238.11.rdns.continuumdatacenters.com.ntp: NTPv4, Client, length 48
02:06:42.976668 IP 74.117.238.11.rdns.continuumdatacenters.com.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:43.093077 IP 192.168.1.6.ntp > perturb.org.ntp: NTPv4, Client, length 48
02:06:43.151417 IP perturb.org.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:43.293119 IP 192.168.1.6.ntp > blackhole.jetta.net.ntp: NTPv4, Client, length 48
02:06:44.693082 IP 192.168.1.6.ntp > fairy.mattnordhoff.net.ntp: NTPv4, Client, length 48
02:06:44.763676 IP fairy.mattnordhoff.net.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:44.893073 IP 192.168.1.6.ntp > 74.117.238.11.rdns.continuumdatacenters.com.ntp: NTPv4, Client, length 48
02:06:44.977155 IP 74.117.238.11.rdns.continuumdatacenters.com.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
02:06:45.093080 IP 192.168.1.6.ntp > perturb.org.ntp: NTPv4, Client, length 48
02:06:45.155882 IP perturb.org.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48                                            
02:06:45.293102 IP 192.168.1.6.ntp > blackhole.jetta.net.ntp: NTPv4, Client, length 48

I'm running the ntp version last updated in the Slackware security patch release:

Code:

root@Slackware:/etc/rc.d# ntpd --version
ntpd 4.2.6p5
ntpd 4.2.6p5@1.2349 Thu Feb 13 22:45:10 UTC 2014 (1)

Additionally, I am behind a Netgear router, but since I'm able to use KDE's "magical" version of ntp... I doubt that has anything to do with it. I also have disabled my iptables.

Anyway, just thought I would add to this... I'll be watching the thread/helping out if/where I can with troubleshooting this.

WilliamS · 05-10-2014, 06:52 AM

FirstHorseman, thanks for the idea. I tried it by first opening another tab and doing ntpq -p, then doing tcpdump udp port 123, after ~9 minutes got the same output from tcpdump.
I use xfce, but kde is installed.

Code:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ks4001083.ip-19 .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 time.netspectru .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 ntp2.torix.ca   .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 noc.digibase.ca .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Code:

# tcpdump udp port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:34:20.651328 IP 192.95.251.217.ntp > ks4001083.ip-198-245-49.net.ntp: NTPv4, Client, length 48
11:34:52.651330 IP 192.95.251.217.ntp > time.netspectrum.ca.ntp: NTPv4, Client, length 48
11:34:55.651330 IP 192.95.251.217.ntp > noc.digibase.ca.ntp: NTPv4, Client, length 48
11:35:02.651345 IP 192.95.251.217.ntp > ntp2.torix.ca.ntp: NTPv4, Client, length 48
11:35:25.651345 IP 192.95.251.217.ntp > ks4001083.ip-198-245-49.net.ntp: NTPv4, Client, length 48
11:35:57.651337 IP 192.95.251.217.ntp > time.netspectrum.ca.ntp: NTPv4, Client, length 48
11:36:02.651346 IP 192.95.251.217.ntp > noc.digibase.ca.ntp: NTPv4, Client, length 48
11:36:07.651334 IP 192.95.251.217.ntp > ntp2.torix.ca.ntp: NTPv4, Client, length 48
11:36:29.651361 IP 192.95.251.217.ntp > ks4001083.ip-198-245-49.net.ntp: NTPv4, Client, length 48
11:37:02.651337 IP 192.95.251.217.ntp > time.netspectrum.ca.ntp: NTPv4, Client, length 48
11:37:08.651335 IP 192.95.251.217.ntp > noc.digibase.ca.ntp: NTPv4, Client, length 48
11:37:12.651334 IP 192.95.251.217.ntp > ntp2.torix.ca.ntp: NTPv4, Client, length 48

Is it possible that the names are getting here, but the data required for updating the clock are getting somehow filtered?
And why 9 minutes for an output?

...an hour and forty minutes later I notice that gkrellm is now showing time in UTC instead of local.

GazL · 05-10-2014, 11:51 AM

The fact that you're not seeing a "NTPv4, Server" reply in your tcpdump strongly suggests that filtering is occurring. That ntpdate appears to work when you use the -u option (which makes it use a different port) is additional evidence that this is occurring.

Something external to your slackware box is either filtering, or just plain losing, udp 123 traffic.

Unfortunately, there is no equivalent to ntpdte's '-u' in ntpd, though I believe you can tell OpenNTPd to use unprivileged ports, so that is always an option if you just can't find the root cause.

FirstHorseman is not even seeing the "NTPv4 Client" messages in his tcpdump output, so that is a different situation to yours.

WilliamS · 05-10-2014, 03:43 PM

Quote:

Originally Posted by GazL

Something external to your slackware box is either filtering, or just plain losing, udp 123 traffic.

Yes, it looks like that.
Called xplornet tech support again; was told they don't "manage" any ports, so to call ViaSat.
Phone # works not from Canada, sent email.

FirstHorseman · 05-10-2014, 09:49 PM

For the life of me, I cannot understand why, but for some reason now ntpd is working. I decided to restart the service again without changing anything (definition of madness right?), now it is working. Like I said, I haven't changed anything in the config from my previous post.

Code:

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+198.100.156.225 213.251.128.249  2 u   36   64  177   99.898   14.825 280.242
+173.208.234.242 206.209.110.2    3 u   35   64  177   82.622   19.461 205.300
*23.239.11.57    129.6.15.30      2 u   37   64  377  138.868   47.811 222.117

tcpdump:

Code:

# tcpdump udp port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:41:07.457158 IP 192.168.1.6.ntp > router.bhs.servme.fr.ntp: NTPv4, Client, length 48
19:41:08.457145 IP 192.168.1.6.ntp > mcclure.whackertech.com.ntp: NTPv4, Client, length 48
19:41:08.704079 IP router.bhs.servme.fr.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
19:41:09.744740 IP mcclure.whackertech.com.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
19:41:12.457163 IP 192.168.1.6.ntp > 173.208.234.242.ntp: NTPv4, Client, length 48
19:41:13.589783 IP 173.208.234.242.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
19:42:13.457144 IP 192.168.1.6.ntp > mcclure.whackertech.com.ntp: NTPv4, Client, length 48
19:42:13.608803 IP mcclure.whackertech.com.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
19:42:14.457158 IP 192.168.1.6.ntp > router.bhs.servme.fr.ntp: NTPv4, Client, length 48
19:42:14.557077 IP router.bhs.servme.fr.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
19:42:18.457163 IP 192.168.1.6.ntp > 173.208.234.242.ntp: NTPv4, Client, length 48
19:42:18.539856 IP 173.208.234.242.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
19:43:17.457161 IP 192.168.1.6.ntp > mcclure.whackertech.com.ntp: NTPv4, Client, length 48
19:43:17.610748 IP mcclure.whackertech.com.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48
19:43:18.457162 IP 192.168.1.6.ntp > router.bhs.servme.fr.ntp: NTPv4, Client, length 48
19:43:18.591457 IP router.bhs.servme.fr.ntp > 192.168.1.6.ntp: NTPv4, Server, length 48

FirstHorseman · 05-10-2014, 10:16 PM

It may be worth noting that prior to my original post yesterday on your thread, that I had removed the ntpd package altogether and then re-installed the last security update for it from here: http://www.slackware.com/security/vi...ecurity.575205

Maybe I just needed to kick it around some more (restart the service again) to get it to work.

Anyway, I apologize if this has already been suggested, but maybe you should try removing the package and re-installing it like I did, to get it back to its "default" state. Then you can walk through the setup process again. Don't forget to mark /etc/rc.d/rc.ntpd as executable again.

Good luck.

tronayne · 05-11-2014, 08:08 AM

Keep in mind that your clocks (both the hardware clock and the system clock) need to be within 1,000 seconds (about 16 minutes) of "actual time" for NTP to synchronize.

At boot, the system time is set from the hardware clock and, conversely, the hardware clock is set from the system clock on shutdown. As you might guess, if the hardware clock is off and the system clock is set from it, it is conceivable that when NTP starts much later in the boot process it won't be able to synchronize; it is also conceivable that, if you set the system clock using ntpdate or ntpd -g -q that, on shutdown the hardware clock will get set to the correct time and on next start the time will be within 1,000 seconds and NTP will synchronize.

It's easy enough to eliminate potential problems if you notice that the system time is off to simply shut down NTP, set the time with ntpdate (or ntpd -g -q) and reboot. You can also shut down, boot into the BIOS and set the hardware clock manually to either UTC or local time depending upon your preference -- just make sure you've got a time source that's within 1,000 seconds of actual time (like maybe your cell phone?).

This all presupposes that UDP port 123 is not being blocked somewhere along the line.

This is what you'll see when it is synchronized (if you see .INIT. in the second, refid, column, after it's been running for about five minutes, it's not going to synchronize):

Code:

ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 219m   64    0    0.000    0.000   0.000
+72.209.167.121  68.0.14.76       2 u   15 1024  377  683.172   21.230  80.668
+169.229.70.201  128.32.206.55    2 u  405 1024  377  585.987   -5.545 112.732
*66.228.35.252   209.51.161.238   2 u  523 1024  377  630.100   -7.134  32.820

And, after some time (up to about 11 minutes), you'll see this:

Code:

tcpdump udp port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:32:03.122520 IP fubar.lan.ntp > ponderosa.piney0.com.ntp: NTPv4, Client, length 48
08:32:03.804767 IP ponderosa.piney0.com.ntp > fubar.lan.ntp: NTPv4, Server, length 48
08:33:46.122518 IP fubar.lan.ntp > ntp3.Housing.Berkeley.EDU.ntp: NTPv4, Client, length 48
08:33:46.744607 IP ntp3.Housing.Berkeley.EDU.ntp > fubar.lan.ntp: NTPv4, Server, length 48

Hope this helps some.