Rapid DHCP

Jiri Popelka jpopelka at redhat.com
Tue Aug 16 14:52:12 UTC 2011


On 08/01/2011 07:15 PM, Dan Williams wrote:
> 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.
Actually the client should be already getting the lease in 2 packets.

When client restarts (connecting after waking from sleep) it needs to 
confirm that its address is still valid.
So it sends REQUEST with the old address. This REQUEST is broadcasted
because the address may be invalid (client has moved to another network),
even if the lease on that address has not expired.

When the server receives the REQUEST it checks that the address is from 
a subnet assigned to the network segment
to which the client is attached.
The server knows what client (MAC) has what address. It's also 
persistently stored in servers leases DB.
The request is then either ACKed (usually), so the client gets the lease 
in 2 packets or
NAKed, in which case new DISCOVER/OFFER/REQUEST/ACK solicitation follows.

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