NTP server issue in PFSense 2.7.2 ?
-
@NollipfSense Well, so far it does resolve the issue.
But I'd like to get a better understanding of why changing one of the default settings is seemingly necessary to have it working at all in 2.7.2.
I'm pretty sure this wasn't an issue in older versions of PFSense, and I have certainly never customised this setting before so I'm guessing that something changed either in the default configuration or the underlying NTP daemon in one of the updates between 2.6.0 and 2.72. (I have upgraded through every intermediate version)
Better understanding of the underlying issue is also helpful for anyone else searching for an answer to this problem who comes across this thread to know whether my suggestion is a good idea or just a workaround.
-
Hmm, nothing has changed with regard to that setting between 2.6 and 2.7.2. You can check the generated file in /var/etc/ntpd.conf.
-
@stephenw10 New binary with slightly different behaviour due to the new FreeBSD base version ?
The ntpd.conf doesn't show anything particularly interesting - the kod option is present or absent in the config file depending on the GUI choice as would be expected.
I don't have a 2.6.0 system handy to see what the default setting for kod is when NTP is installed, or what ntpd.conf is generated however - is it possible the default setting for kod has changed at some point ?
-
It's possible the kod option is interpreted differently.
-
-
@serbus Hi,
Related, yes - they are seeing the same problem I was.
I don't agree with their conclusion that there is a "bug" in the Nagios plugin though.
The whole purpose of the plugin is to be run once every 5 minutes during a Nagios (or in my case LibreNMS) polling session to confirm whether the NTP server is responsive or not.
It is not a "real" ntp client, it just sends a static ntp client request and checks to see if an answer is received, it does not keep any internal state so would not know how to "back off" in response to a KOD packet.
If I turn KOD back on (which triggers the ntpd server to restart) the very first request from the check_ntp_time plugin is rejected, and all subsequent requests are as well, even if I leave it a long time between requests.
I would expect at least the first query to be allowed if the real cause is rate limiting, but every single request is rejected when KOD is enabled. (What is the actual value of the rate limit ? How many minutes per request per client ? I haven't seen it documented anywhere)
As a workaround one could use "Custom Access Restrictions" to create a custom configuration for the IP address of the LibreNMS/Nagios monitoring server where KOD is disabled to allow it to poll freely.
However in my case I have around 60 IP cameras that are each polling every 10 minutes (changing this is outside my control) and I want the ntp queries to always be answered, so I guess I just disable KOD and be happy that I found a solution, and hope that anyone else having the same issue finds my thread. (which is the real reason I posted about this as I already had a solution before posting)
-
Hello!
I dont think the problem is that you are calling check_ntp_time too frequently. My understanding is that the code inside the check_ntp_time was making numerous, non-delayed queries to the ntp server, which is what triggered the kod detection.
It looks like a --delay option flag was added to the code that you can use the prevent the KoD.
https://nagios-plugins.org/doc/man/check_ntp_time.html
John
-
Did disabling KoD also affect the ntp updates at the cameras?
-
@serbus If each invocation of check_ntp_time is making numerous queries with no delay (why ??) as you say, it causing a problem would make sense. It seems like pretty dumb default behaviour.
The delay option looks like it could be a workaround, the problem is without trial and error I don't know what timing would and wouldn't be considered acceptable to the KoD algorithm as I haven't seen this documented.
I think in my case I'll just keep KoD disabled as all clients are an internal network.
Edit: just checked and found the version of check_ntp_time on the system doesn't support the delay option. (Ubuntu 22.04.4 LTS, installed via APT)
-
Hi - hard to be sure, as there's not really any diagnostics or logging available on the camera UI's to test NTP, other than just setting the time to be wrong then trying to force an update, which I'm not keen to do manually on over 60 cameras...
The proof of the pudding will be if they start drifting out of time again, but that will take a while to find out.
I think in my specific use case of it only serving specific internal clients that disabling KoD is the best option.
