Linked by Thom Holwerda on Wed 13th Jul 2011 14:09 UTC
Internet & Networking "One of life's minor annoyances is having to wait on my devices to connect to the network after I wake them from sleep. All too often, I'll open the lid on my EeePC netbook, enter a web address, and get the dreaded 'This webpage is not available' message because the machine is still working on connecting to my Wi-Fi network. On some occasions, I have to twiddle my thumbs for as long as 10-15 seconds before the network is ready to be used. The frustrating thing is that I know it doesn't have to be this way. I know this because I have a Mac. When I open the lid of my MacBook Pro, it connects to the network nearly instantaneously. In fact, no matter how fast I am, the network comes up before I can even try to load a web page. My curiosity got the better of me, and I set out to investigate how Macs are able to connect to the network so quickly, and how the network connect time in other operating systems could be improved." Yes, I'd love to have Windows and Linux reconnect as fast as Macs do. Alas, "Method to quickly reconnect to a wireless or wired network", as well as its completely different "Method to quickly reconnect to a wireless or wired network on a mobile device" are probably patented, so Windows and Linux can't reconnect too fast out of fear of violating a software patent. In case you haven't noticed: I'm joking. Sort of.
Thread beginning with comment 480823
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

This may be too much to ask, but I'd like to look at a wireshark dump of the traffic from an external interface.

That would give a fairly definitive answer to the question of "why" it's taking so long.

Of course things should just work. If I am right about the client just sitting there waiting to send the next packet, well the DHCP spec is at fault. A non-compliant implementation wouldn't have to wait so long before retries.


On my home router, here are the dhclient sequences.

// no pre-existing IP leases
0.0s execute dhclient
3.0s dhclient sends DHCP Discover
3.5s router responds with DHCP Offer
3.5s dhclient sends DHCP Request
3.5s router responds with DHCP ACK

I repeated this 3 times, same results. I find it very odd that the first packet isn't transmitted immediately. Maybe the dhclient guys deliberately delayed the first packet to give the network time to settle, but an arbitrary delay could conceivably cause race conditions which are exacerbated by wifi.


// pre-existing IP lease
0.0s execute dhclient
3.0s DHCP Request
3.0s DHCP Ack

This looks totally normal, the 3s delay served no purpose here, but the DHCP server acked immediately.

// cold start, no DHCP server
3.0s DHCP Discover.
11.0 DHCP Discover
23.0s DHCP Discover
30.0s DHCP Discover
45.0s DHCP Discover
55.0s DHCP Discover

So assuming the Wifi hasn't connected within 3s (which seems plausible from a cold start as opposed to merely a standby mode), the dhclient (using default ubuntu settings) won't even try again until 11s.

This could very well be Thom's problem.

Reply Parent Score: 2