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". The NTP lab is quite simple: a "master" server with local clock running ntpd with leapfile feature, and a "client" system also 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 is ignoring the flags, as I say: this only happens on Debian running 4.2.6.p2 from upstream, not on CentOS with 4.2.4p8.
CentOS master NTP config = works OK
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.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
Debian master NTP config = leap-second not forwarded from master to the client
leapfile "/etc/leap-seconds.list"
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
server 127.127.1.1 iburst
fudge 127.127.1.1 stratum 10
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
The unique difference between CentOS and Debian config files is leap-second settings, it depends on ntpd version, the remaining conf is the same on both master and client servers.
This is the NTP config on the clients:
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
server 10.204.3.2 iburst
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
What can be the reason that blocks leap-second being forwarded on Debian/4.2.6.p2 systems?
