r7 - 2006-03-01 - 01:37:13 - HarlanStennYou are here: NTP >  Dev Web > LoseThePerDriverPPSCode
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.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Lose the per-driver PPS code

What Status
Master bug_small.png Bug #557
arbiter (seems OK)
as2201 (seems OK)
hpgps (seems OK)
jupiter bug_small.png Bug #560
msfees bug_small.png Bug #561
mx4200 bug_small.png Bug #562
nmea bug_small.png Bug #563
oncore bug_small.png Bug #559
parse bug_small.png Bug #558
ripencc bug_small.png Bug #564
trak bug_small.png Bug #565
true bug_small.png Bug #566
zyfer bug_small.png Bug #567

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.

ALERT! This issue is currently on-hold - we need more discussion about this point.

IDEA! The original topic name (LoseThePer-driverPPSCode) was not a WikiName (which interferes with the automatic link creation). I've moved the content here and changed the original topic to be a redirect. -- SteveKostecke

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

It would be nice to have ntpq display the appropriate peer tally code depending on the health of PPS for ATOMized drivers

-- SteveKostecke - 01 FEb 2006

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r8 < r7 < r6 < r5 < r4 | More topic actions...
Dev.LoseThePerDriverPPSCode moved from Dev.LoseThePer-driverPPSCode on 2006-02-01 - 13:37 by SteveKostecke - put it back
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback