GNOME Bugzilla – Bug 726121
Doesn't reconnect to wifi after resuming from suspend
Last modified: 2020-11-12 14:33:10 UTC
Using FC20 with GNOME 3.11.x via Copr and NetworkManager 0.99. I have two networks in range that are configured to connect automatically. When connected to one then sleeping, on wake my laptop doesn't reconnect. Manually selecting the network to collect via GNOME's 'select network' option from the top bar works fine, as does selecting it from the relevant GNOME Shell settings page.
I have exactly the same. I am on Kubuntu Utopic (with nm 0.9.8 and kernel 3.18.2 from kernel ppa). The problem did not occur on Trusty (same nm version), but I suspect it has something to do with the scan interfering with the association proces. I seems that there is some timing aspect so that sometimes the automatic connect after resume work immediately, sometimes not. Can't figure out if it depends on the suspended time, relocating to another room. I've tried fixes that kill thing on resume to no avail. The only thing that works consistantly is disabling autoconnect and connecting manually through the kde nm widget. My card is ath9k (AR9462 abgn + bt). The acces point that I connect to is in the 5G band. Need logs? Ferry
Created attachment 295322 [details] manual connection with atheros syslog with comments of a manual connection to an AP followed by a manual connection to another AP
Created attachment 295323 [details] autoconnect atheros succes syslog with comments showing succesfull reconnection after suspend/resume
Created attachment 295324 [details] autoconnect atheros fail syslog with comments showing failed autoreconnect after suspend/resume followed by infinite retries
Created attachment 295325 [details] Autoconnect intel with succes Syslog from other machine (NUC) with Intel Wireless abgn + bt (functionally equivalent to atheros), with same Kubuntu 14.10 + kernel 3.18.2 from Kernel PPA
For some reason, the autoconnect state machine is different from manual connect and gets confused sometimes with the AR9462, while the Intel 7260 always works. It seems also that messages in syslog don't arrive in the exact order in way they occur. That makes it hard for me to understand what is exactly going on. Maybe there's a better way for me to debug this? To be complete: the AR9462 is running on a (ex) Chromebook Acer 720p now loaded with Kubuntu 14.10. The kernel has been updated to 3.18.2 as 3.16 will not support the touchscreen and touchpad correctly. This thing has a SSD and will wake up faster than I can open the lid (let alone type the pw to unlock the screen). With Kubuntu 14.04 the network connection would then already be completed. 14.10 seems to be slower (when succesful).
Can we at least set this bug to confirmed?
Most components in bugzilla.gnome.org don't make any use of the distinction between UNCONFIRMED and NEW. I think this might finally get fixed (by dropping UNCONFIRMED) in the upcoming bugzilla upgrade.
Any ideas what is the difference in the state machine when autoreconnecting after resume vs. manual reconnect?
Exact same problem with the exact same card here (Acer C720 with AR9462). All my computers are running Ubuntu 14.04 LTS at the moment. However, I've noticed two things: -It isn't limited to suspend/resume. Try clicking nm-applet, disable WiFi (*don't* disconnect first), wait a few seconds and enable it again (of course having it reconnect automatically). This will fail in the exact same way as resuming after suspend does. - It seems to depend on the access point. I have two routers, and I only see this problem with one of them. On the other, I can disconnect/auto-reconnect like a mad man and it will succeed every time. Also, the problem seems to be limited to the AR9462 as far as I can tell now (and not even ath9k). I have six computers, all with Atheros cards (2x AR9485, 3x AR9285 and 1x AR9462). All other computers disconnect/auto-reconnect perfectly on both access points, even if I attempt to do it over and over again. When the auto-reconnect starts failing, I have to disconnect manually, uncheck the "automatically connect when available" checkbox, restart NetworkManager, and reconnect manually. And even then I usually have to wait about five minutes before the AP wants to associate again. Here's a small snippet from dmesg, repeated many times: [ 5413.165695] wlan0: authenticate with <BSSID> [ 5413.183669] wlan0: direct probe to <BSSID> (try 1/3) [ 5413.384668] wlan0: direct probe to <BSSID> (try 2/3) [ 5413.588607] wlan0: direct probe to <BSSID> (try 3/3) [ 5413.792598] wlan0: authentication with <BSSID> timed out In the mean time, connecting to my other AP, either manually or automatically, works just fine. Therefore, I also think that it might be a problem with the connection state, as was said here: https://mail.gnome.org/archives/networkmanager-list/2015-February/msg00011.html I guess that my other AP is just less strict about it and my other WLAN cards don't seem to disagree about the connection state. Either way, it's just this one machine having issues with one AP. Although I may add that it happens on both 2,4GHz and 5GHz. Unfortunately, the C720's WLAN chip is soldered to the mainboard, so I can't swap it out. I have, however, bought another AR9462 on eBay to test in another laptop. But it may take a while before I'll receive that one.
Created attachment 296662 [details] syslog of continuous failed connection attempts Here's the interesting part of /var/log/syslog when auto-reconnect fails on my machine.
Hmm, I did some more tests to make sure the problem wasn't in my installation. So I booted some live images: Ubuntu 14.04 desktop iso --> failed miserably Ubuntu 14.10 desktop iso --> failed miserably Ubuntu 15.04 daily build --> worked like a charm I think I've disconnected/auto-reconnected and suspended/resumed the 15.04 image at least fifty times, and it succeeded on all occasions. I did some 'sudo service network-manager restart's and some 'sudo rmmod ath9k && sudo modprobe ath9k's as well, and the network keeps coming back up perfectly. So I think it's safe to say that whatever is causing this is fixed somewhere between NetworkManager 0.9.8.8 and 0.9.10.0, or another part of the network stack updated in 15.04 compared to 14.10. The only thing I don't think is causing it, is the kernel, as I was already using 3.19 on 14.04 LTS. With 14.04 being a long-term release, I feel like this should be backported. I'm just not sure what actually fixed this. It may not even have been NetworkManager at all.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).