data: lease_time: lease ends at 1248109552 when it is now 1248109556

[David W. Hankins]

On Tue, Jul 21, 2009 at 03:26:45PM +0200, sthaug at nethelp.no wrote:
> Have you checked the clock on the devices with the problem? If those
> devices were off by some seconds, and decided to release the IP at
> the end of the lease period, I believe you could get just the effect
> that you have seen.

The DHCP protocol sends a lease time in absolute seconds.  The client
uses that time as an offset from its current clock.

Example:  The DHCP server sends '300', the client adds time(NULL)+300
and schedules expiry at that time.

So what's more common is for a client to obtain an IP address with
an unsynchronized clock, it schedules expiration based upon that
clock but the next thing it does upon gaining an IP address is to
ntpdate (before ntpd), so the clock gets skewed.  If it goes forward,
the client just renews earlier, or maybe expires right away, no harm
done.  If it goes backwards, the client effectively holds the lease
longer than it was granted, possibly causing addressing collisions.


I've been trying for some time to figure out a strategy to cope with
this issue in dhclient, with little success.

If we use the system uptime clock rather than the unix epoch clock
then we have a clock that consistently increases over time hopefully
irrespective of epoch clock skews (depending on host OS
implementation, but from what I've seen I think it's pretty
consistently an uptime counter).  But we need to be able to re-use a
lease that we cached from a previous runtime, which means we still
need to use the epoch clock, so we're almost back where we started.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090721/1d242e4e/attachment.bin>