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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
