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 794024 - NetworkManager fails to reconnect after wake from sleep
NetworkManager fails to reconnect after wake from sleep
Status: RESOLVED NOTABUG
Product: NetworkManager
Classification: Platform
Component: Wi-Fi
1.10.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2018-03-03 14:58 UTC by Severo Raz
Modified: 2019-02-09 20:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
journalctl log of NetworkManager (35.98 KB, application/octet-stream)
2018-03-03 14:58 UTC, Severo Raz
Details

Description Severo Raz 2018-03-03 14:58:09 UTC
Created attachment 369224 [details]
journalctl log of NetworkManager

Most of the time, when I wake my laptop up, the network connection to my WiFi network fails.

I think this is due to NetworkManager because I can fix it by turning Wi-Fi off, turning it back on, and trying to connect again; most of the times this workaround is successful at the first time, otherwise I have to give it a couple of tries.

I have attached a log of what journalctl records when this happens. (The log may contain more information than requested.)
Comment 1 Thomas Haller 2018-03-04 16:31:00 UTC
If you look at the logfile, you see that associations times out. There is on information why that happens. You should probably enable debug logging of the supplicant and see what it says there.



You might want to try to disable MAC address randomization, because that sometimes trips supplicant up. You do that with a file like

/etc/NetworkManager/conf.d/99-no-wifi-scan-rand-mac-address.conf

with content

[device-no-wifi-scan-rand-mac-address]
wifi.scan-rand-mac-address=no

(and restart NM).
Comment 2 Severo Raz 2018-03-31 12:19:26 UTC
Thanks for the answer, will do to see what happens. By supplicant you are referring to wpa_supplicant right?
Comment 3 Severo Raz 2019-02-09 12:35:10 UTC
Thomas, I forgot to report back, but it worked perfectly! However, it is only a workaround. What info is needed on my behalf to solve this issue?
Comment 4 Thomas Haller 2019-02-09 14:04:27 UTC
Actually, changing/randomizing the MAC address should generally work.

1) some drivers don't support changing the MAC address. These drivers should be fixed.

2) wpa-supplicant had some issues when NetworkManager changed the MAC address (which it does without telling supplicant). I think these issues there are fixed. If you are using latest supplicant and there is still an issue, that should be investigated.

3) NetworkManager in the past did worse when it failed to change the MAC address. I think, today it should just cope with that and go on. Dunno if there is something missing here.


From the <info> level logfile it's not clear to see. But it seems the driver changed the MAC address fine (1), and hence NM wouldn't have a problem with it (3). Hinting more to a supplicant issue.

Make sure your wpa-supplicant is recent. Maybe this patch matters: 
https://w1.fi/cgit/hostap/commit/?id=77a020a118168e05e7cc0d28a7bf661772e531af


Unrelated to this issue (since you say, that disabling MAC address changes avoided the issue) is that wifi-sec.pmf setting sometimes breaks Wi-Fi. See https://fedoramagazine.org/troubleshoot-pmf-f28/



I am gonna close this a NOTABUG. Please reopend if you are wiling to provide more information about your issue. We'd need at least level=TRACE logs and the exact versions of NM, supplicant and driver. Or if you think anything else should be done here. Thanks!!
Comment 5 Severo Raz 2019-02-09 20:05:09 UTC
Thanks for the info and time! I'll find a time to get this information and reopen then.