NTP and stratum issue
-
you are using an older version of ntpdate.. Why don't you just update it?
Current dev version is 4.3.88 it is syncing fine to pfsense ntp server
user@clean:~$ ntpdate -d pfsense.local.lan
1 Jan 21:46:42 ntpdate[29545]: ntpdate 4.3.88@1.2483 Mon Dec 28 22:23:20 UTC 2015 (1)
Looking for host pfsense.local.lan and service ntp
192.168.9.253 reversed to pfSense.local.lan
host found : pfSense.local.lan
transmit(192.168.9.253)
receive(192.168.9.253)
transmit(192.168.9.253)
receive(192.168.9.253)
transmit(192.168.9.253)
receive(192.168.9.253)
transmit(192.168.9.253)
receive(192.168.9.253)
server 192.168.9.253, port 123
stratum 3, precision -18, leap 00, trust 000
refid [192.168.9.253], delay 0.02600, dispersion 0.00003
transmitted 4, in filter 4
reference time: da31c5f2.447ed54e Fri, Jan 1 2016 21:43:46.267
originate timestamp: da31c6a8.e20bc1c1 Fri, Jan 1 2016 21:46:48.882
transmit timestamp: da31c6a8.e1e17584 Fri, Jan 1 2016 21:46:48.882
filter delay: 0.02606 0.02605 0.02606 0.02600
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000203 0.000183 0.000202 0.000250
0.000000 0.000000 0.000000 0.000000
delay 0.02600, dispersion 0.00003
offset 0.0002501 Jan 21:46:48 ntpdate[29545]: adjust time server 192.168.9.253 offset 0.000250 sec
user@clean:~$ -
Thanks for the help! I love being the first to find version mismatch bugs.
Rather than update the entire office of OSX clients and Freenas servers to a newer version of ntpdate, I think we're just going to make ntpdate an alias to 'ntpd -qg -c <special config="">' or something along those lines. That way we don't have to worry about dependencies etc.
I'll probably file a bug with Freenas also so someone else doesn't waste an afternoon chasing this one down.</special>
-
Dude but isn't 4.2.4p5 really really freaking old?? didn't 4.2.4p5 come out in like Aug of 2008?? What version of os x and freebsd are you running that that would be the ntp version?
So help validate this, I grabbed an OLD version for windows - couldn't find the exact 4.2.4p5 but p8 pretty close, and yeah fails..
-
stratum 16, precision -6, leap 11, trust 000
See exactly the same with a older CentOS (guess 6.4) Server, Debian 7/8 works.
-
Yeah it looks like there is a issue between versions of ntp.. What version of ntp is the centos box running
-
What version of ntp is the centos box running
Don't know which version was affected, now it is a CentOS 6.7 with ntp.x86_64 4.2.6p5-5.el6.centos.2 and it working as expected.
-
ntpdate is rather bitrotted and has been on the pathway to deprecation for some time.
Depending on the usage case, sntp or ntpd -gq should be used - the link in the previous paragraph gives some background and implementation considerations.
FreeBSD base system only abandoned ntp 4.2.4 in the second half of 2015.
-
Rather than update the entire office of OSX clients and Freenas servers to a newer version of ntpdate, I think we're just going to make ntpdate an alias to 'ntpd -qg -c <special config="">' or something along those lines. That way we don't have to worry about dependencies etc.
I'll probably file a bug with Freenas also so someone else doesn't waste an afternoon chasing this one down.</special>
It was reported here that choosing certain parameters in NTP access restrictions would work around this bug in older ntpdate client versions. I haven't tested myself, but if it works then you wouldn't have to touch each client.
Yes, 'ntpd -gq' is the right approach going forward, but it may not be practical to upgrade client machines.
-
So looking at that thread.. And a simple test with old ntpdate, its the KOD packet that is killing the old version for some reason..
If you uncheck the Kiss-o'-death, then ntpdate from old client works… If you have it enabled then it fails with stratum 16, and leap 11
edit: Seems if kod is enabled, it also places a limited in the restrictions, which is a conflict when you have no monitor set as well, which is in the conf file but don't see anyway in the gui to edit that.
Jan 5 04:05:38 ntpd[11014]: restrict: 'monitor' cannot be disabled while 'limited' is enabled
If you uncheck kod, then the kod is removed from the conf as well as the limited.
disable monitor
statsdir /var/log/ntp
logconfig =syncall +clockall +peerall +sysall
driftfile /var/db/ntpd.drift
restrict default nomodify nopeer notrap
restrict -6 default nomodify nopeer notrapIf you check the kod option in access restrictions you get
disable monitor
statsdir /var/log/ntp
logconfig =syncall +clockall +peerall +sysall
driftfile /var/db/ntpd.drift
restrict default kod limited nomodify nopeer notrap
restrict -6 default kod limited nomodify nopeer notrap
-
And a simple test with old ntpdate, its the KOD packet that is killing the old version for some reason..
If you uncheck the Kiss-o'-death, then ntpdate from old client works… If you have it enabled then it fails with stratum 16, and leap 11
In this case, kiss-of-death is working as intended, but ntpdate earlier that some time during the 4.2.7 cycle fails to understand it.
Dave Hart posted an excellent analysis of this scenario in the comp.protocols.time.ntp newsgroup.
I found:
discard average 6 minimum 0
got my ntp servers working with old ntpdate binaries and kiss-of-death enabled. -
why wouldn't you update vs downgrade.. I show it working with current ntpdate.
-
why wouldn't you update vs downgrade.. I show it working with current ntpdate.
It's a compatibility thing. Nothing here runs ntp older than 4.2.8p4 (4.2.8p5 has just released), but there are circumstances where older remote clients need to run against my servers.
-
Thank you for this topic. Was pulling my hair out why my Thecus nas was the only device not able to sync with time my pfsense box.
All test done from my windows pc showed no issues. Looking on the nas I found out it is not using ntpd / ntpq but ntpdate (ntpdate 4.2.4p8 to be exact)throug a long way of searching came to this topic.
After setting "ACL - Custom Access Restrictions" in pfSense for the IP of my NAS and disabeling KOD, all is working fine
-
Glad the topic was of use of you HeMan.. When I saw this show up as something new it - was at first ah shit some spammer necro an old thread ;) Nice to see it was someone actual used the info contained in old threads for what they are meant for ;)
