NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15
was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Lose the per-driver PPS code
Dave wants to lose the per-driver PPS code and let the ATOM driver handle it all.
Let's use this topic to discuss issues about this set of bugs.
Harlan: Do the remarks "seems OK" mean - OK as they do not use any of the PPSAPI?
--
FrankKardel - 01 Feb 2006
Yes, it means that I did a
grep PPS refclock*.c
and the ones marked "seems OK" only discussed PPS in their comments.
--
HarlanStenn - 01 Feb 2006
The thing is that the refclock drivers know exactly whether the PPS of the
device they are controlling is valid by the information from the device itself.
ATOM/PPS must use PPS derived time stamps only when the clock is doing well.
ATOM/PPS has currently no way whatsoever to know about the health state of PPS
(I currently see a 500ppm frequency check) - it assumes that PPS is always valid
when it is there.
We have seen refclock/network scenarios where knowing whether PPS is healthy was
absolutely crucial (effect: oscillating clock setting of several 100ms).
The scenario was invalid PPS information from a PPS source and valid time
time information from the network.
For ATOM/PPS we would need an interface where the PPS health information is
available to ATOM/PPS.
Currently this task is managed in the refclock drivers (some better, some worse).
--
FrankKardel - 01 Feb 2006