Hi...

Just wanted to let you know that we have been hit by this as well.

We're booting linux on systems which usually run Windows.
We bring up the network and then call ntpdate to correct time.
If ntpdate steps the time backwards (which it occasionally does), then
dhclient does not renew its lease when it should, and continued use of
the IP address is prevented by the switch we're connected to.

I suspect this has been happening for years, but we've only noticed now
that our network is "smarter" and drops packets from machines which
don't have a valid lease.

It's not clear why ntpdate sometimes needs to step time backwards
(timezone issues? flaky ntp server?), but the point is that we must be
able to get from a state where the system clock is unknown to a running
state. Since we can't run ntpdate before starting dhclient, we either
need dhclient to handle backward time steps, or we need to hack our way
around it (LD_PRELOAD trick, set system time to epoch on boot, or
detect negative time step and kill dhclient).

It would be far nicer if dhclient could handle this itself.


Cheers,


Nick
-- 
Nick Phillips / nick.phillips@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago