NTP failure on 1.2.3 RC3?
Hmmm…I'm having trouble figuring this one out. Running pFsense 1.2.3-RC3 on an Alix board, and everything was running fine last week, and NTP was fine. A couple days ago we noticed the NTP server now isn't working. After the unit rebooted I let it sit for a day, then retested NTP, and either we get the "Peer's stratum is less than the Host Stratum" or "NTP Rejected because its been too long since peer synchronized". None of the Windows or Linux boxes want to play NTP with the pfSense box anymore. I tried freshly booting pfSense and everything else seems working. I waited an hour after reboot and still no NTP. The URL's below are working fine from my location.
listen on 192.168.200.1
Any clues on what's going on? Otherwise the system is working perfectly, and it had no problem last week, and has been running for several months. pfSense itself seems to know what the correct time and day it is.
UPDATE: The NTPD service shows its running, but the OpenNTP log is empty. ?????
I've seen this happen after I did an update to pfSense but not when NTP had been working and then just quit.
If you go to "Diagnostics" then "Command" you can run the ntpdate command from the "Execute Shell command" section. For your time servers try:
This should sync your pfSense time server.
I tried starting and stopping NTP server.
I tried going to Command / Execute / ntpdate time-a.nist.gov
Another start / restart NTP. nothing.
SSH into the shell and execute ntpdate time-a.nist.gov from there, and get the "Server unusable to synchronize"
Then I tried stopping ntpd and then:
ntpdate -d time-a.nist.gov
That worked. Then I started the NTP service and it seems to be running again.
Then I power-cycled pfSense, and wait an hour to see if NTP would start on its own: No dice. Its back to being offline again.
So there is something squirrly here (???) with ntpd not always starting without having to issue an ntpdate to get the clock "sort of" close??
CMOS battery dead so that power cycle causes clock to go backwards in a big way?
Yes, there is something goofy. At boot time, If the clock is totally un-initialized, or if close to the correct time, it looks like NTP will start up OK. But if the clock is un-initialized but really wrong, it looks like NTP won't start. I'm playing with it some more this week.
Otherwise NTP is 100% un-reliable on this in case of a power outage, etc.
Are you running pfSense on an ALIX 2/3 machine? Because they don't have a clock battery, the clock resets every time it's rebooted (though you can add a battery if you want to get your soldering iron out). If you're not using ALIX, then chances are your CMOS battery is dead. However NTPd is there precisely for the reason to compensate for the lack of a hardware clock.
However, when a clock is out of sync but a HUGE margin like this, NTP sort of goes into a panic mode and starts wondering whether to believe the system clock or reset it. The reason is NTP under normal operation will only fix drift by up to 2 seconds per second (this is at least under Linux, not sure about FreeBSD). When the date is completely out of whack, like 1970 vs 2009, it 'panics' (not a kernel panic, just an NTP panic) and its behaviour isn't really 100%.
The best way to deal with this is for pfSense to actually save the time at shutdown somewhere, and reset it (even if it's not totally accurate) at boot time, so NTP can then fix the time from this less-drifted reference rather than from 1970. The only way to fix it really is to manually set the time and then let NTP do it's thing.
Finally, pfSense also uses OpenNTPD, which is a cut down and considerably simpler and smaller version of NTP, which is more than fine if you're only running stratum2/3 with a pool.ntp.org reference. However if you want 'proper' NTP (especially with sub 1.0us accuracy and GPS/10MHz reference or being a pool host), then not having a dedicated box tuned for NTP and accuracy would be silly.