X-RT-Original-Encoding: utf-8
content-type: text/plain; charset="utf-8"
Content-Length: 3337

If you came here looking for quick fix you can use LD_PRELOAD with
gettimeofday() replacement.
You can freely grab the solution from
https://github.com/kunschikov/ld_preload_gettimeofday
Just export LD_PRELOAD from some network configuration script, which is
being sourced from other start/stop scripts.

On RedHat CentOS it can be done by adding line
    export LD_PRELOAD=/usr/lib64/libgettimeofday.so
to the end of the
   /etc/sysconfig/network

It fixes this behavior for sure.

More solid (and proper) fix will require replacement of time calculation in
dhclient itself.  Of course it will require recompilation of dhclient.

2017-12-21 13:53 GMT+03:00 Ferry van Steen via RT <dhcp-public@isc.org>:

> 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.
>
>
>