Comment 17 for bug 1407928

@Julia

Thanks for the testing report!

So when you say, "you gave it 10/15 minutes of time to reconnect on its own". I assume during this time you were assuming that the device would re-connect automatically when the screen was off?

Then you say you woke the phone, and it was offline until you started to interact with the network menu. Can you give us a rough idea of how long it was between when you woke the phone, and it connected? My experience have show that it's usually somewhere between 30s and 2m to connect.

Finally, the original bug describes a situation where after the phone is woken, it will *never* re-connect to an available access point it's previously been connected to.

@ Pete

Regarding passive network scanning... no, none of the sort happens, in fact we have no code at all in our network stack that integrates with our power management framework on touch devices.

At some point, the screen turns off, which given the right conditions causes powerd to notify the kernel that it's allowed to sleep. When this happens ( ie. the kernel decides to suspend given no more wake locks ), there's no notification to wpa_supplicant or NetworkManager, and in some cases we've seen this "pulling of the rug" approach actually prevent some devices from suspending.

Enabling passive scanning during suspend is something that could be accomplished automatically by the driver, or enabled by wpa_supplicant before suspend, however without some knowledge of the system power/suspend mechanism, neither wpa_supplicant or NM can do this today. Making such a thing work, also would require deeper technical cooperation from the ODM and/or IHV.

Note, we also should seriously consider a new system settings for WiFi that allows a user to specify whether or not WiFi is to attempt to keep a connection going when the system goes to suspend. I would argue that our current situation is a bit ambiguous ( ie. WiFi remains on, but at some point when the device suspends, it does disconnect ).