GNOME Bugzilla – Bug 790571
Wifi connection fails on startup since version 1.10.0
Last modified: 2017-11-28 05:12:58 UTC
My system: Arch Linux with KDE, default kernel My hardware: Lenovo Thinkpad X1 carbon, 5th generation Since the last update of the networkmanager package in the arch repos, the automatic connection to wifi networks on startup fails on my system. The upstream commit id in this version of the networkmanager package is 1193fb1b08fe45ce8713220132184581c4669362 (tag 1.10.0^0) Here is the relevant output of 'journalctl -xe': Nov 19 21:07:54 thinktux NetworkManager[427]: <info> [1511122074.6236] device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed') Nov 19 21:07:54 thinktux NetworkManager[427]: <info> [1511122074.6241] manager: NetworkManager state is now DISCONNECTED Nov 19 21:07:54 thinktux NetworkManager[427]: <warn> [1511122074.6248] device (wlp4s0): Activation: failed for connection 'tuxmobil' Nov 19 21:07:54 thinktux NetworkManager[427]: <info> [1511122074.6258] device (wlp4s0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') Nov 19 21:07:54 thinktux kernel: IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready Nov 19 21:07:54 thinktux NetworkManager[427]: <info> [1511122074.6341] device (wlp4s0): set-hw-addr: set MAC address to 36:DA:1E:AA:10:9D (scanning) Nov 19 21:07:54 thinktux kernel: IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready Nov 19 21:07:54 thinktux plasmashell[599]: Currrent active notifications: QHash() Nov 19 21:07:54 thinktux plasmashell[599]: Guessing partOf as: 0 Nov 19 21:07:54 thinktux plasmashell[599]: New Notification: "Drahtlose Schnittstelle (wlp4s0)" "Es wurde kein Passwort angegeben" -1 & Part of: 0 Nov 19 21:07:54 thinktux plasmashell[599]: Currrent active notifications: QHash(("notification 2", "NetzwerkverwaltungDrahtlose Schnittstelle (wlp4s0)")) Nov 19 21:07:54 thinktux plasmashell[599]: Guessing partOf as: 0 Nov 19 21:07:54 thinktux plasmashell[599]: New Notification: "tuxmobil" "Die Verbindung tuxmobil wurde deaktiviert." -1 & Part of: 0 Nov 19 21:07:54 thinktux NetworkManager[427]: <info> [1511122074.6732] device (wlp4s0): supplicant interface state: scanning -> disconnected Nov 19 21:07:54 thinktux NetworkManager[427]: <info> [1511122074.6784] device (wlp4s0): supplicant interface state: disconnected -> inactive Nov 19 21:07:54 thinktux wpa_supplicant[450]: wlp4s0: Reject scan trigger since one is already pending This happens only for automatic connection on system startup. I am able to establish wifi-connecitons normally using the network applet of KDE afterwards. This bug does not seem to be related to the arch package nor to the KDE networkmanager applet. I tried to build the networkmanager package undoing all changes in the PKGBUILD since the last version except for the upstream commit id, and still face the error. If I leave the PKGBUILD unchanged except for reverting the upstream commit id to 51fdc50ab179a0582012d1b50e587761765ad15e (tag 1.8.4^0), then the problem does not occur. I set up my wifi connections using the KDE builtin network-applet, with autoconnect enabled. This is purely speculative: my laptop (thinkpad x1 carbon) is really fast, KDE starts within less than 2 seconds. Maybe it could be some kind of race condition, with network manager trying to establish the connection before the authentication data is accessible... It could be something totally different though... Please ask if I can provide more usefull informations or help in any way...
apologizing for the dirty and incomplete syslog paste in the bug description... I'm adding complete syslogs: with networkmanager-1.8.4-1 (everything ok): https://pastebin.com/f9JfZtvT with networkmanager-1.10.0-1 (automatic connection after boot fails): https://pastebin.com/WRpsN9sU The most interesting line (for me) is this: Nov 20 22:14:29 thinktux NetworkManager[419]: <info> [1511212469.6283] device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
can you enable level=TRACE logging an provide a new logfile? See https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/contrib/fedora/rpm/NetworkManager.conf?id=master
Hi Thomas, here are the new logs: networkmanager-1.8.4-1: https://pastebin.com/re5PfAhF networkmanager-1.10.0-1: https://pastebin.com/gQP9ay9c
there is a race in the 1.10 log. It's not clear, that the same issue could not also happen in 1.8. Does it always happen with 1.10, but never with 1.8? [1511468634.5759] device (wlp4s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed') [1511468634.5772] device (wlp4s0): No agents were available for this request. [1511468638.4082] agent-manager: req[0x55ea7e58a5d0, :1.32/org.kde.plasma.networkmanagement/1000]: agent registered [1511468638.4082] policy: re-enabling autoconnect for all connections with failed secrets [1511468664.6280] device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed') [1511468664.6287] policy: connection 'tuxmobil' now blocked from autoconnect due to no secrets
it never happens with 1.8... Thank you for investigating into this!
And yes, it always happens with 1.10.
Can you try if the connection succeeds after disabling WPS with: nmcli connection modify tuxmobil wifi-sec.wps-method disabled ?
I will, but won't have the possiblity until this sunday...
Hej Benjamino, disabling wps with your command helped, connection succeeds :-) Do you need a log?
(In reply to Pascal Pollet from comment #9) > Hej Benjamino, disabling wps with your command helped, connection succeeds > :-) Do you need a log? No, logs not necessary. Thanks. Suggested fix on https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/user-block-autoconnect-rh1401515 Commit "core: fix race of blocking autoconnect for no-secrets when a new secret-agent registers" I packed the fix on top of a larger rework for autoconnect-handling, sorry about not providing a self-contained fix. But I anyway intend to backport the entire branch to nm-1-10 stable branch.
should be fixed now. master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e2c8ef45ac9fba8d4f5722ab10831bf42085a110 nm-1-10: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=118b9f29785834bd3790b17ac0314c1cac23c2a5 thanks for reporting.
Thanks for fixing! I tried to build nm with both commits, but here is no autoconnect and the kde-nm-applet crashes when I try to establish a connection. I think it's not related to your fix, but if you think the master branch should work on my system, I'd happily help with logs or something else :-) btw, I will report another bug soon, which is most probably also due to a race condition. Keeping you busy ;-)
A GUI crash (KDE plasma-nm in this case) is unrelated to this issue. A crash is certainly a bug in plasma-nm. The bugtracker for plasma-nm is https://bugs.kde.org/describecomponents.cgi?product=plasma-nm However, maybe the newer version of NM triggers the crash by some undesired change in behaviour (and unwanted API change). That shouldn't happen, hard to say whether that's the case without understanding why the GUI crashed.