content-type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-RT-Original-Encoding: utf-8 Content-Length: 3492

Hi,


Hope this will get added to bug 45540, don't have an account on the bugtracker and can't comment with guest access.


for us this is a pretty severe issue and quite surprised you are surprised this hits anyone.


For obvious reasons NTP won't run until the network is activated and there's several cases where the clock will be stepped by it:

* You multiboot and the hardware clock is stored by the other OS in a different timezone

* Your hypervisor handles it differently than expected

* OS stores clock in localtime, you multiboot, summer-/wintertime occurs and OS'es aren't aware of the other OS already has made the switch

* Systemclock is off by a lot


And probably more.


This issue has been open on the RedHat bugtracker for quite some time (years). Not sure if it wasn't filed at ISC earlier as the bugtracker apparently wasn't open to the public at all some time ago.


You can find it here: https://bugzilla.redhat.com/show_bug.cgi?id=1093803


The issue seems to be:

Hardware clock is stored in localtime. We're in UTC+1 (wintertime, UTC+2 in summer). So say it's 14:00.

System boots, linux assumes hardware clock in UTC, adds 1 (or 2 depending on summer/winter) hours to hardware clock and sets system clock to 15:00

dhclient fires up, obtains a lease with a lease time of 15 minutes. dhclient sets a trigger/timer on 15:15 to renew (well, actually 15:07:30 but let's ignore that for ease)

NTP starts, steps system clock back to 14:00

14:15 lease expires, something removes it (presume the kernel - doesn't get logged). At this point your network is dead. It doesn't come back to live again either as:

At 15:15 dhclient tries to renew, but lease has expired. So DHCP won't renew. It apparently doesn't try to obtain a new lease at that point either as the network remains dead.


At many places this isn't an issue as leasetime > clock shift. But more and more networks are switching to low lease times due to BYOD and a lot of roaming phones and laptops and guest devices using up leases.


Haven't tested what happens if the clock is shifted the other way around, which is normal for half the world being west of UTC, but it's at best a pretty nasty issue for anyone east of UTC.


Kind regards,

______________________________________________________

This message may contain confidential or privileged information. If you are not the addressee, please notify the sender and delete it from your files. Please consider the environmental impact before printing this e-mail.