Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    NTP failure on 1.2.3 RC3?

    Scheduled Pinned Locked Moved General pfSense Questions
    6 Posts 4 Posters 4.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      WallyJ
      last edited by

      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.

      pfSense OpenNTPD configuration file

      servers time-a.nist.gov
      servers 0.us.pool.ntp.org
      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. ?????

      1 Reply Last reply Reply Quote 0
      • T
        TreeTopFlyer
        last edited by

        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:

        ntpdate time-a.nist.gov

        This should sync your pfSense time server.

        1 Reply Last reply Reply Quote 0
        • W
          WallyJ
          last edited by

          I tried starting and stopping NTP server.

          I tried going to Command / Execute / ntpdate time-a.nist.gov

          Nothing.

          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??

          1 Reply Last reply Reply Quote 0
          • W
            wallabybob
            last edited by

            CMOS battery dead so that power cycle causes clock to go backwards in a big way?

            1 Reply Last reply Reply Quote 0
            • W
              WallyJ
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • M
                MrHorizontal
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.