r8 - 2007-03-25 - 20:26:14 - PoulHenningKampYou 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.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.

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

I would like to chime in here, and say that I disargee 100% with Dave on this.

The nature and properties of the GPS signal are only know to the relevant refclock driver, and instead of evicting all the PPS handling to the ATOM driver, we should create an API which the refclocks can use to get PPS-API (or other APIs as relevant) service for a given filedescriptor.

One very clear example of why involving the ATOM driver is the wrong way to go is the oncore refclock. The oncore transmits T-RAIM status, estimated error, necessary corrections and other PPS contextual information in the serial data stream, and instead of giving the ATOM driver an unwieldy interface for generalizing these data, it would be simpler for to give the refclock_oncore the timestamps and implement the necessary corrections and policies in the refclock where the necessary information is already present.

I will also add, that in my "NTPns" implementation, this is in place and working, so anybody claiming that this is "impossible" or "unpractical" has a bit of uphill argument in front of them.

-- PoulHenningKamp - 25 Mar 2007

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-2022 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