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 480774
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

- Android connects, assumes it is using the last address ( on the last network and tries twice to continue as such (with a ~4 second timeout) before starting from scratch.

The delay he is experiencing on his phone is partly due to a misconfigured dhcp server.

A dhcp server can be configured to operate in two modes, "authoritative" and "non authoritative".

If the server was in "authoritative" mode, it would have immediately take charge of the request and told his android phone its now on a different network and it will be up to his phone to make dhcp discover request or to use the response it got from the authoritative server to notice what network is in and if the ip address it got previous is still active or not and if not.

His dhcp server is configured to be "non authoritative" and that is why it keeps quiets when it sees dhcp requests targeting another network and this silence causes his phones hang around waiting for a response wasting time before giving up and making dhcp requests.

His misconfigured dhcp server is partly to blame for the delay he is seeing

Reply Parent Score: 4

Alfman Member since:


You may be right.

But why would a DHCP server ever be coded to ignore an IP request within it's range?

Assuming the client went to sleep on the same lan that it wakes up on, then it's most likely the requested IP matches the one provided by the DHCP server.

But I guess this is a good question for Thom, is the device woken up on the same network? Or did it get transported from another before being woken up?

Edit: I completely missed the context of who you were responding bad, but I'll leave the question for Thom.

Edited 2011-07-13 20:23 UTC

Reply Parent Score: 2

Soulbender Member since:

Good question but it is an option for a DHCP server to be authorative or not. Never had to make use of the non-authorative option but it's there none the less.

Reply Parent Score: 2

mtzmtulivu Member since:

But why would a DHCP server ever be coded to ignore an IP request within it's range?

I think the proper word is "configured", not "coded".

There could be a bunch of reasons, one i can think if is:

If you have a bunch of computers that have static ip addresses manually configured, you may want to tell your dhcp server not to issue those addresses to anybody and to reject anybody who ask for them

Edited 2011-07-13 20:54 UTC

Reply Parent Score: 2

Soulbender Member since:

So in other words his findings are completely null and void.

Reply Parent Score: 2