After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 596469 - [enh] optimize reconnect on resume
[enh] optimize reconnect on resume
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: Dan Williams
Dan Williams
: 582842 597743 664289 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-09-26 22:39 UTC by Jaap A. Haitsma
Modified: 2012-08-24 14:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jaap A. Haitsma 2009-09-26 22:39:26 UTC
A Mac is within a second online after it wakes up from sleep. Somehow it does this by caching network configurations I think
Comment 1 Jaap A. Haitsma 2009-09-27 11:58:18 UTC
Seems that according to people wicd is much faster 
http://wicd.sourceforge.net/
Comment 2 Dan Williams 2009-10-01 20:59:14 UTC
Apple is also able to highly optimize their drivers.  There are a number of issues at play here:

1) NM only asks for scan results once after resume.  If this fails, NM waits 20 seconds until it requests them again.  If we fail immediately after starting up or resuming from sleep, NM should re-request the scan.  Eventually we should just dump all configured wifi networks into the supplicant's config with appropriate priorities and let it handle most of that.

2) The supplicant is a bit stupid, and after NM tells it to connect using known-good AP info, the supplicant performs another scan.  The supplicant should get fixed to use existing scan results if they are less than 10 or 15 seconds old.  This right here would save at least 3 to 5 seconds of connection time.

3) The gnome-keyring doesn't unlock successfully after the screensaver disappears; or really, it doesn't unlock the keyring and dismiss open keyring dialogs at that time, which prevents NM from connecting faster because it can't get your wifi secrets.
Comment 3 Jaap A. Haitsma 2009-10-02 04:36:36 UTC
Good to hear that there are wins available on the non-driver level
Comment 4 Dan Williams 2009-10-16 02:43:05 UTC
*** Bug 597743 has been marked as a duplicate of this bug. ***
Comment 5 Nicolò Chieffo 2009-10-16 08:05:45 UTC
From the duplicate bug:

Dan Williams:
"sounds like the first scan is timing out; my iwl5100 card is always connected
within 5 seconds or so.  What hardware do you have?  In any case, -> the duped
bug."

My answer is that I have the same card in ubuntu 9.10. I have to wait 15 seconds for the connection to be detected, than other almost 10 seconds to be extabilished.
I'm using a wireless configured with "available for all users"
Comment 6 Dan Williams 2009-11-30 19:18:46 UTC
The fix for #2 above is:

http://lists.shmoo.com/pipermail/hostap/2009-November/020617.html

And yeah, it really does help.
Comment 8 Dan Williams 2010-01-04 21:40:58 UTC
*** Bug 582842 has been marked as a duplicate of this bug. ***
Comment 9 Dan Winship 2012-05-02 16:50:23 UTC
*** Bug 664289 has been marked as a duplicate of this bug. ***
Comment 10 Pavel Simerda 2012-08-24 14:54:05 UTC
We probably only need to maintain individual bug reports for specific problems.