In my case, (v149), NTP has never worked as a proper NTP client, only as a SNTP client which updates hourly. Is Ipfire meant to do full NTP?
NTP depends on what your configuration asks to IpFire…
I should have added that if I update the time manually (while still
configured to update automatically) it always seems to update OK.
you may want to add your NTP configuration (menu Services > Time Server) and your NTP messages (menu Logs > System Logs >> Section NTP) to this thread to help debug.
All done as above but Ipfire is still not a true NTP client. (it is a Simple NTP client - SNTP)
Once an hour (the shortest interval allowed) my firewall does a hard time synch to the chosen upstream server and then proceeds to drift off frequency for an hour until the next update.
A true NTP client will want to see multiple upstream servers and then will start off synching to them at 64 second intervals and as the internal clock adjusts itself, will slow to about every 17 minutes.
This might help:
It adds a few lines to ntp.conf to make it act as you expected.
log.zip (1.24 KB)
Did this help?
Sadly - No
Ha! You’re going to need to give better hints on what is happening on your side. This is hard to fix otherwise…
ls -al /etc/ntp
and post the results.
Hmm. I had similar problem after installation. I added manually some time servers into
/etc/ntp.conf, and restarted ntpd. Now
ntpq -p -n gives reasonable output. Maybe this could be documented on the Services → NTP Configuration page?
Hi Juha - Thank you for your post. Please take a moment to update and improve the NTP IPFire Wiki page. It is open to you (and everyone else) to improve and make better. You would login using the same ID and password as this Community.
If you have issues or questions, feel free to post a question. I’d be happy to help!
Well… What I would really want, is that the Services → Time Server cgi-script would install those Primary and Secondary NTP servers into
/etc/ntp.conf. This is also what I think users expect. If this were done, there would be no need for manual editing. And we could get rid of the Synchronization dialog, because synchronization is just what real NTP is for .
For the purpose of verification, it would be useful to let
ntpd produce statistics. It takes a few more lines in /etc/ntp.conf. Here is a nice picture of how it works after I made these changes i my system:
You need to alter /etc/ntp.conf and turn off the 1 hour sync.
Mine looks like
More stuff here I just posted:
I think I am correct but if someone knows better I am all ears.
You may need to restart all hosts behind the firewall to pick up setting as they will all be syncing with their local clock. As far as I can see NTP is not working on IPFire and never has. THink I had to make the same changes to my IPCop install as well!
I see that ipfire.pool.ntp.org is not working at the moment.
How is this meant to be maintained?
I just manually ran it, it did update.
I just had to chnage my ntp conf again to get ntp working correctly…
[root@wr-fw ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 60 64 377 0.000 +0.000 0.000 [root@wr-fw ~]# cat /etc/ntp.conf-01 disable monitor restrict default nomodify noquery restrict 127.0.0.1 server 127.127.1.0 prefer fudge 127.127.1.0 stratum 10 driftfile /etc/ntp/drift
[root@wr-fw ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.au.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 1.au.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 2.au.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 3.au.pool.ntp.o .POOL. 16 p - 64 0 0.000 +0.000 0.000 bitburger.simon .GPS. 1 u 7 64 7 66.088 +17.137 52.880 any.time.nl 220.127.116.11 2 u 7 64 7 51.028 +21.269 51.868 18.104.22.168 ( 22.214.171.124 2 u 10 64 7 52.973 +21.902 51.417 ntp2.ds.network 126.96.36.199 4 u 11 64 7 7.019 +21.396 51.591 time.cloudflare 10.84.8.4 3 u 12 64 7 6.542 +21.216 51.657 x.ns.gin.ntt.ne 249.224.99.213 2 u 15 64 7 53.703 +23.776 51.615 toc.ntp.telstra 188.8.131.52 2 u 10 64 7 6.101 +19.268 51.533 ntp1.ds.network 184.108.40.206 4 u 16 64 7 7.038 +21.764 51.995 pauseq4vntp2.da 220.127.116.11 2 u 13 64 7 55.383 +22.052 51.303 ntp.seby.io 18.104.22.168 2 u 15 64 7 51.082 +20.947 51.853 y.ns.gin.ntt.ne 249.224.99.213 2 u 16 64 7 53.568 +25.298 52.200 time.cloudflare 10.84.8.4 3 u 13 64 7 6.581 +19.633 52.201 61-68-38-238.st 22.214.171.124 3 u 11 64 7 6.414 +18.791 52.401 ec2-13-55-50-68 126.96.36.199 3 u 12 64 7 47.739 +19.313 51.808 eth817.qld.adsl 172.22.254.53 2 u 12 64 3 73.448 +19.447 33.210 188.8.131.52 .PPS. 1 u 16 64 3 72.347 +21.210 31.913 184.108.40.206 (d 220.127.116.11 2 u 19 64 1 51.149 +21.280 0.000 [root@wr-fw ~]# cat /etc/ntp.conf disable monitor restrict default nomodify pool 0.au.pool.ntp.org pool 1.au.pool.ntp.org pool 2.au.pool.ntp.org pool 3.au.pool.ntp.org fudge 127.127.1.0 stratum 10 driftfile /etc/ntp/drift
all right, let’s shed some light on this…
This is completely intentional. Please refer to the NTP Pool Project’s homepage for further information on how the NTP pool architecture works.
ntpd sometimes gets confused if the internet connectivity is flapping. Because of this and some other reasons, we decided to move on to
chrony, being a more robust software with a smaller footprint. Unfortunately, time is currently short, and priorities laid elsewhere (kernel 5.10.x in particular).
Thanks, and best regards,