dhclient fails when not using UTC in hwclock

[David W. Hankins]

On Fri, Apr 14, 2006 at 02:12:25PM +0200, Ricardo Pérez López wrote:
> https://launchpad.net/distros/ubuntu/+source/dhcp3/+bug/33968

That ticket appears to have the solution already encoded in it.

dhclient deals with time warps very, very poorly.  Which is to say,
it doesn't deal at all...it just sticks its head in the sand and
assumes they never happen.

So I think, and it's very hard to be sure of this because I'm
not seeing a lot of log lines just some snippets, this is what's
happening to you:

Your dhclient is not maintaining state across invocations (perms
problem on dhclient.leases in your logs).  So it should start up
with the idea it has no leases it could possibly use and transmit
a DISCOVER.  I presume this is working, that you get a lease, and
what's breaking is that dhclient fails to renew it.

So when you've set UTC=no, your time() (which is supposed to return
UTC always) returns UTC+7200.  Your lease-time is 3116 seconds.  So
it sets expiration to ocurr at eg UTC+10316, and RENEW to ocurr at
eg UTC+8758).

Later, your clock is adjusted to be ~UTC.  The dhclient is unaware
of this clock skew, and retains a lease RENEW event timer set to
UTC+8758, 8758 seconds in the future now.

This is a long time to wait for a renewal...


It's kind of a chicken and egg problem.  You need an IPv4 address
even to run ntpd to know your clock is correct.

In general if the clock is very close to the correct time when
dhclient runs, and things like ntpd operate to keep that clock
moving in real seconds as it goes, there should be few issues.

But it's still a problem if the clock starts out at UTC+5, dhclient
gets an address, and the NTP daemon slowly moves the clock back 5
seconds as it goes...assuming renew and rebind fail and the client
goes to expiration on this lease, it'll do so 5 seconds late.  A
slow slew just slowly ruins our time coordinate.

Or it's even a problem if you run dhclient, then ntpdate right
after, and your clock was way off one way or the other.

I've toyed with the idea of using the system uptime - this is a
clock that is fixed to a reference event, rather than a common
coordinate system.  current_uptime + X should always be 'x seconds
in the future' not 'x +/- y seconds of synchronization slew'.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins