On Mon, 2011-08-01 at 12:10 -0500, Dan Williams wrote: > On Sat, 2011-07-30 at 19:41 -0400, Nathaniel McCallum wrote: > > Dan, that works on wireless networks. On wired networks the ARP > > technique determines *which* of the valid leases you should attempt to > > restore. So on a wired network you: > > Right, which is why I noted a couple of times about wifi specifically, > but perhaps not as clearly as I should have. Obviously NM doesn't yet > know which network you're on for wired, and ARP can help there. > > > 1. ARP the known DHCP server IPs to discover the subnet. > > 2. ARP the IP from the valid lease on that subnet to avoid collision. > > 3. Restore the ifconfig from the still valid lease. > > 4. Renew the lease. > > > > This should be pretty sane and gives large speedups to resuming on > > wired (which people with docks do a lot). > > Yup, though on wired the impact is a lot lower since medium is a lot > more reliable than wifi, and DHCP tends to happen a lot more quickly. > The problem with wired is that broadcast and multicast frames often end
Should read "The problem with wifi", not wired. > up getting dropped because they aren't necessarily re-transmitted when > there's interference or channel contention. That usually doesn't happen > on wired networks. But yes, it can help speed things up on wired, and > it can help determine what connection we should be associating with the > link as you describe. > > Dan > > > Nathaniel > > > > On Jul 30, 2011 6:45 PM, "Dan Williams" <d...@redhat.com> wrote: > > > On Sat, 2011-07-30 at 11:46 -0400, Genes MailLists wrote: > > >> On 07/30/2011 10:37 AM, Lennart Poettering wrote: > > >> > On Sat, 30.07.11 10:31, Genes MailLists (li...@sapience.com) > > wrote: > > >> > > > >> >>>> http://cafbit.com/entry/rapid_dhcp_or_how_do > > >> >>> > > >> > > >> > > > >> > IIRC connman (i.e. NM's competition) can do the ARP magic, too. > > >> > > > >> > Lennart > > >> > > > >> > > >> > > >> Seems like a pretty reasonable thing to do - surely better than > > just > > >> waiting for a timeout to decide if the server is not there ... are > > you > > >> aware of any gotcha's ? > > > > > > NM already keeps DHCP information around based on the network you're > > > connecting to, so we don't need to ARP a bunch of servers just to > > > determine whether the DHCP server we wanted is still there. dhclient > > is > > > smart enough to attempt to reclaim the lease if it's not already > > > expired. Note that the Mac attempts to ARP a number of different > > DHCP > > > servers (192.168.2.1, 192.168.4.1, 192.168.1.1) which would be > > pointless > > > with NetworkManager, because it's extremely unlikely that the DHCP > > > server on your wifi network has changed; NM would simply know that > > the > > > last DHCP server used *on that wifi network* was 192.168.1.1 and not > > > bother to try talking to other ones like Mac OS X appears to do. > > > > > > NM could use the same method of ARPing multiple DHCP servers that > > Mac OS > > > X does, but it wouldn't provide much additional benefit, if any, at > > > least on WiFi networks. It could be used on wired networks to (a) > > > determine which wired network you're connected to, and (b) do rapid > > > DHCP. Again, NM already knows what DHCP server and what lease was > > last > > > used on the specific wifi network you just connected to, and it > > won't > > > bother doing a DISCOVER, it'll just jump to RENEW if your lease is > > still > > > valid. > > > > > > What's unique about the method described there is that the Mac > > > configures the interface with the same IP address it previously had > > if > > > the lease is still valid, while NetworkManager waits for the DHCP > > server > > > confirm the lease. So we could presumptuously configure the > > interface > > > with the previous address from the lease and then only tear it down > > if > > > the DHCP server fails or rejects the renewal. > > > > > > Of course, none of this helps if your DHCP leases are short, but it > > > certainly helps if you put your laptop to sleep a lot and wake it up > > in > > > the same location. > > > > > > Dan > > > > > > -- > > > devel mailing list > > > devel@lists.fedoraproject.org > > > https://admin.fedoraproject.org/mailman/listinfo/devel > > > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
