Rapid DHCP

Dan Williams dcbw at redhat.com
Mon Aug 1 17:15:17 UTC 2011


On Sun, 2011-07-31 at 12:25 +0200, Reindl Harald wrote:
> 
> Am 31.07.2011 12:17, schrieb David Woodhouse:
> > On Sat, 2011-07-30 at 16:37 +0200, Lennart Poettering wrote:
> >> IIRC connman (i.e. NM's competition) can do the ARP magic, too.
> > 
> > I don't think so. ConnMan doesn't remember the last DHCP setup at all,
> > and doesn't even set the DHCP_REQUESTED_IP option — so it gets
> > gratuitously changed IP addresses each time it reconnects to the
> > network
> 
> should it be not the job of the DHCP-Server to remember what
> IP the MAC got and if it should get a knew one?

Yes, the server should be caching leases and returning the same IP
address to the client when the client requests it, if the lease is still
valid.  If the lease is no longer valid, the server forces a new
DISCOVER/REQUEST/ACK sequence, which can take a long time.

The client can make this process quicker by using unicast RENEW requests
to the DHCP server if the lease is still valid, in which case you can
skip the whole broadcast DISCOVER process and possibly get your lease in
2 packets (RENEW then ACK) instead of 4 or 5 with a random backoff in
between if you have to DISCOVER.

So both sides need to do some work to make things go as quickly as
possible.

> for me the only right thing the client can do is waking up
> and request a new IP, so you got everytime a new one if
> your location was changed and if the dhcpd remembers the
> MAC the same you had last there

This is what happens unless we know we're reconnecting to a saved
network, in which case if the lease is still valid we can simply request
our old address and chances are the server will ACK that request, and
then things are faster.  No sense in requesting a completely new IP if
the lease we were given by the server is still valid.

Dan



More information about the devel mailing list