[ntp:questions] WARNING: someone's faking a leap second tonight
jeffrey.lerman at gmail.com
Thu Aug 2 16:10:42 UTC 2012
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. 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.
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.
On 8/2/2012 7:20 AM, Martin Burnicki wrote:
> Jeffrey Lerman wrote:
>> How are the leap-second flags meant to be cleared after a leap second?
>> Is it supposed to be automatic? Is there a bug in some code (ntpd or
>> elsewhere) that is failing to clear the flag in (some versions of) ntp
>> server software?
> I've just run some tests. On a test machine:
> - configured ntpd to use the current leap second file
> - configured the local clock as only ref time source
> - set the system date/time to 2012-06-30 23:59:45 UTC
> - started ntpd
> On a different machine:
> - ran a test program which sends 4 requests/s to the test machine
> and prints the contents of the reply packets, including leap status
> Found that with both the current stable version (4.2.6p5) and a
> current dev version (4.2.7p290) the leap second warning in the reply
> packets already disappeared shortly *before* the leap second actually
> This means if this server sends a reply to a client shortly before the
> leap second the leap warning may have already been turned off, and
> thus the client might *disarm* the leap second shortly before the leap
> second occurs. This sounds like a bug to me, so I'm going to file a
> bug report for this.
> Anyway, this does *not* seem to be directly related to the actual
> problem where the leap bit is not reset at all, or is set again if
> there's a time source which still has the bit set immediately after
> the leap second.
> For completeness I've repeated the same test with the latest version
> of the 4.2.4 branch, namely 4.2.4p8. This version of ntpd resets the
> leap warning bit in the leap status sent to clients a few seconds
> *after* the leap second, so this could be a possible issue for clients
> accepting a new leap warning immediately after a leap second has
>> I did check earlier this morning and I was unable to
>> find a bug filed against ntpd regarding this issue - does anyone know if
>> we should go ahead and file a bug? It'd be nice to have more
>> information on whether this is really an ntpd issue.
> I'm sure a bug will be filed, but eventually we should first find out
> more details so we can write an appropriate summary of the issue.
More information about the questions