Leap-second flag not forwarded to NTP clients

[Santi Saez]

Hello,

I'm making some tests with "leapfile" feature on ntpd to send fake
leap-seconds and ensure our Linux platform is resilient to the bug :)

Lab is quite simple: a "master" server with local clock running ntpd
with leapfile feature, and a "client" system also running ntpd that
connects to the "master".

I have just found that leap-second flag is forwarded from the "master"
to the "client" without problems on CentOS-6 boxes (running 4.2.4p8-2),
but with the same configuration it doesn't work on Debian Squeeze
(4.2.6.p2+dfsg-1+b1). If I query ntpd it returns "leap_add_sec" and
"leap=01" flags, and running a tcpdump I also see those flags, but the
"client" system seems that it's ignoring the flags, as I say: this only
happens on Debian running 4.2.6.p2 from upstream.

This is the config on CentOS systems = works OK

* master

driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server 127.127.1.0 iburst
fudge 127.127.1.0 stratum 10
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
keysdir /etc/ntp
crypto pw password

* client

driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server 172.16.2.1 iburst
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys

This is the config on Debian systems = leap-second not forwarded from
"master" to the "client"

* master

leapfile "/etc/leap-seconds.list"
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server 127.127.1.1 iburst
fudge 127.127.1.1 stratum 10
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys

* client

driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server 10.204.3.2 iburst
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys

The unique difference is the way leap-second is configured, it depends
on ntpd version [1], the remaining conf is the same on both master and
client servers.

What can be the reason that blocks leap-second being forwarded on
Debian/4.2.6.p2 systems? Thanks!

[1] http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14.1.

Santi Saez

[Santi Saez]

El 14/08/12 12:34, Santi Saez escribió:

> I have just found that leap-second flag is forwarded from the "master"
> to the "client" without problems on CentOS-6 boxes (running
> 4.2.4p8-2), but with the same configuration it doesn't work on Debian
> Squeeze (4.2.6.p2+dfsg-1+b1). If I query ntpd it returns
> "leap_add_sec" and "leap=01" flags, and running a tcpdump I also see
> those flags, but the "client" system seems that it's ignoring the
> flags, as I say: this only happens on Debian running 4.2.6.p2 from
> upstream.

(..)

> What can be the reason that blocks leap-second being forwarded on
> Debian/4.2.6.p2 systems?

Seems that it's a version specific behavior, with a "forward"-port
package from Lenny (4.2.4p4+dfsg-8lenny3) on Squeeze works as expected:
leap seconds fields are forwarded to the clients.

How can I achieve the same behavior with ntpd 4.2.6.p2+dfsg-1+b1 on
Squeeze? Just for the record: I want to forward leap-second flags
between NTP servers, thanks :)

Santi

[E-Mail Sent to this address will be added to the BlackLists]

Santi Saez wrote:
> The unique difference is the way leap-second is configured,

> it depends on ntpd version, the remaining conf is

> the same on both master and client servers.

Run the same version on all servers / clients under your control?
{Perhaps even a current version.}

--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.

[Santi Saez]

El 21/08/12 23:24, E-Mail Sent to this address will be added to the
BlackLists escribió:

> Run the same version on all servers / clients under your control?
> {Perhaps even a current version.}

After making some tests with different ntpd versions, I have found that
"leap second" fields are only forwarded on 4.2.4, and it doesn't work
after 4.2.6, still don't know the reason or if I need a special
configuration.

Santi Saez

[Dave Hart]

On Wed, Aug 22, 2012 at 13:29 UTC, Santi Saez <sa...@woop.es> wrote:
> After making some tests with different ntpd versions, I have found that
> "leap second" fields are only forwarded on 4.2.4, and it doesn't work after
> 4.2.6, still don't know the reason or if I need a special configuration.

I suspect the difference in leap bit propagation between 4.2.4 and
4.2.6 you observe is because 4.2.6 requires a majority of survivors
have the leap bit set to propagate, and because you are (likely
ill-advisedly) using the undisciplined local clock driver
(127.127.1.x) which never sets the leap bit. Either remove the driver
or add remote sources to ensure the leap vote is won.

Cheers,
Dave Hart