[ntp:questions] WARNING: someone's faking a leap second tonight

Martin Burnicki martin.burnicki at meinberg.de
Fri Aug 3 09:09:09 UTC 2012


Jeffrey Lerman wrote:
> Assuming that the current ntpd design spec is that:
>
>    a) Leap second flags can be cleared by EITHER the passage of the
> actual leap second, OR the receipt (at any time) of a LI=0 from the
> current upstream server
>    b) Leap second flags can be set by receipt (at any time) of LI != 00
> from the current upstream server (or also from reading a leap-second file?)
>
> Then it seems that it's important that the leap status in reply packets
> be correct at all times.

On Unix-like systems supporting kernel PLL the leap second warning 
received from an upstream server, from a refclock, or from a leap second 
file is simply passed down to the kernel, starting an hour or so before 
the leap event time.

The kernel then cares about handling of the leap second, so ntpd has to 
wait until the kernel has finished doing so, and then ntpd can disarm 
its internal leap second warning which is passed to its clients.

> If there is even the slightest deviation in
> the moment at which a server's reply packet LI value changes to 00, then
> there will be trouble -- too soon and we risk clients missing the leap,
> too late and we risk arming a bogus leap.

In my opinion "too soon" would have more impact here since clients could 
disarm their leap second handling if they receive a reply from a server 
without leap warning shortly before the leap second.

It would be very hard to have ntpd disarm its leap status immediately 
when the kernel has finished handling the leap second. It could be 
polling the kernel's status to see when the kernel has cleared his leap 
flag, but the result would also depend on *when* the *kernel* clears the 
leap flag.

> Bearing in mind that I don't know if the actual design spec matches what
> I wrote in a) above, but assuming for argument's sake that it does: It
> seems to me that that's a brittle system.  One way to add robustness
> would be to program clients to independently set LI=00 during, say the
> first half of the month, and to ignore the LI value from servers during
> that time.  That provides a (very long!) buffer time during which the
> server can get around to zeroing the LI field, and should prevent bogus
> seconds from propagating easily.

That sounds reasonable, and I could have sworn ntpd would refuse to 
accept a new leap second warning a few seconds after a leap second had 
just occurred. However, this does not seem top be the case.

Maybe a restriction in ntpd to accept incoming leap warnings only during 
the last days of a month would help.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list