GNOME Bugzilla – Bug 665680
gnome-shell starts asking for network password auth constantly
Last modified: 2021-07-05 14:30:24 UTC
Now and then something breaks in gnome shell and it starts asking for the WPA2 password on each and every connect to the network. Generally this start happening after a suspend. To get it back I have to log out and in again. Alt+F2 r is not sufficient. Sometimes it breaks even further and stops asking for the password, even though the indicator is in a state where it is waiting for one. Since there is no way to disconnect from a network, it is rather annoying to get out of this state. The hardware wifi switch is generally the only fix.
If restarting the Shell isn't enough, then that's a bug in NetworkManager itself. What version are you using, and on which distro? Also, have a look at your ~/.xsession-errors and /var/log/messages.
In case you're wondering, I'm waiting for this to happen again so I can get relevant logs.
A variation of this just happened. The machine was freshly booted at work today. I then suspended the machine at the end of the day and resumed back home. At that point it was stuck at "Authentication required". Alt+f2 r did however work this time.
Created attachment 203266 [details] messages messages from when the suspend was initiated until it stalled waiting for the secret.
Created attachment 203267 [details] xsession-errors Entire xsession-errors (as there are no time stamps there).
That's maybe not the same bug, but sounds interesting: Window manager warning: Log level 8: g_signal_handler_disconnect: assertion `handler_id > 0' failed JS ERROR: !!! Exception in callback for signal: destroy JS ERROR: !!! message = '"No signal connection 4 found"' JS ERROR: !!! lineNumber = '74' JS ERROR: !!! fileName = '"/usr/share/gjs-1.0/signals.js"' JS ERROR: !!! stack = '"_disconnect(4)@/usr/share/gjs-1.0/signals.js:74 ([object Object])@/usr/share/gnome-shell/js/ui/popupMenu.js:962 _emit("destroy")@/usr/share/gjs-1.0/signals.js:124 ()@/usr/share/gnome-shell/js/ui/popupMenu.js:144 ()@/usr/share/gnome-shell/js/ui/status/network.js:188 ([object _private_NMClient_DeviceWifi],[object _private_NMClient_AccessPoint])@/usr/share/gnome-shell/js/ui/status/network.js:1298 "' JS ERROR: !!! Exception was: TypeError: apObj is null JS ERROR: !!! lineNumber = '1306' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/status/network.js"' JS ERROR: !!! stack = '"([object _private_NMClient_DeviceWifi],[object _private_NMClient_AccessPoint])@/usr/share/gnome-shell/js/ui/status/network.js:1306 "' JS ERROR: !!! message = '"apObj is null"' JS ERROR: !!! Exception in callback for signal: destroy JS ERROR: !!! message = '"No signal connection 4 found"' JS ERROR: !!! lineNumber = '74' JS ERROR: !!! fileName = '"/usr/share/gjs-1.0/signals.js"' JS ERROR: !!! stack = '"_disconnect(4)@/usr/share/gjs-1.0/signals.js:74 ([object Object])@/usr/share/gnome-shell/js/ui/popupMenu.js:962 _emit("destroy")@/usr/share/gjs-1.0/signals.js:124 ()@/usr/share/gnome-shell/js/ui/popupMenu.js:144 ()@/usr/share/gnome-shell/js/ui/status/network.js:188 ([object _private_NMClient_DeviceWifi],[object _private_NMClient_AccessPoint])@/usr/share/gnome-shell/js/ui/status/network.js:1298
apObj is null is an infamous message that's been fixed in the latest version of GNOME Shell. Not sure about the other message.
(In reply to comment #7) > apObj is null is an infamous message that's been fixed in the latest version of > GNOME Shell. Not sure about the other message. Seems PopupMenu is not clearing signals for destroyed menu items, so it will complain if an object is destroyed more than once. Patch coming...
Created attachment 203292 [details] [review] PopupMenu: disconnect from 'destroy' signals of destroyed items After an item is destroyed, all its signals were disconnected, except for 'destroy' itself. This could lead to exceptions, if destroy was called more than once on the item.
Review of attachment 203292 [details] [review]: What's the case where an object is destroyed more than once?
Review of attachment 203292 [details] [review]: Makes sense to me. Jasper - it can happen whenever there are circular references, and those are quite frequent when signal handlers are involved. The GObject "dispose" vfunc needs to handle multiple invocations for this reason.
Attachment 203292 [details] pushed as a7bd9f8 - PopupMenu: disconnect from 'destroy' signals of destroyed items
Ops, git bz fail...
See Bug 668251 for a related problem: password auth dialogs keeps appearing automatically, and passphrase is lost.
Also see bug 665431
Does this still happen with 3.4?
Will tell you once Fedora 17 is out. :)
Ping?
Patience. ;) Things have been hectic with a new product release at work, and moving to a new place in my free time. Hasn't been room for computer upgrades quite yet. :)
So it is believed that this is fixed by now. Please reopen if this is not the case.
Waiting for Fedora 18 to have a working upgrade path. I'll reopen if it turns out to still be broken. :)
Well, Fedora doesn't seem to be getting their shit together anytime soon. Tried Fedora 17, with Gnome 3.4. Problem remains. Reopening.
Upgraded to Fedora 18/Gnome 3.6. Still getting spurious WPA questions.
Looks like NM 0.9.8 may well fix this bug: https://mail.gnome.org/archives/networkmanager-list/2013-February/msg00156.html
Hi Pierre, I see that NM 0.9.8 has now been included in updates for Fedora 18, so perhaps you could check if this issue is finally solved now (barring confusing bugs like https://bugzilla.redhat.com/show_bug.cgi?id=917317 )
Still buggy, but in a different manner. Resumed the machine at work (where I usually get these spurious auth requests), and nothing popped up. But it also did not connect. Tried clicking the network manually. Nothing happened. Checked the logs: Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> Activation (wlan0) starting connection 'Cendio' Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> Activation (wlan0/wireless): access point 'Cendio' has security, but secrets are required. Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0] Mar 4 11:08:02 mjolnir NetworkManager[642]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Mar 4 11:08:03 mjolnir NetworkManager[642]: <warn> No agents were available for this request. Mar 4 11:08:03 mjolnir NetworkManager[642]: <info> (wlan0): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7] Mar 4 11:08:03 mjolnir NetworkManager[642]: <info> Marking connection 'Cendio' invalid. Mar 4 11:08:03 mjolnir NetworkManager[642]: <warn> Activation (wlan0) failed for connection 'Cendio' Mar 4 11:08:03 mjolnir NetworkManager[642]: <info> (wlan0): device state change: failed -> disconnected (reason 'none') [120 30 0] Mar 4 11:08:03 mjolnir NetworkManager[642]: <info> (wlan0): deactivating device (reason 'none') [0] Mar 4 11:08:03 mjolnir NetworkManager[642]: <warn> (wlan0) firewall zone remove failed: (32) UNKNOWN_INTERFACE: wlan0 Did "Alt+F2 r". Now the spurious auth dialog popped up, and it was able to connect. IOW, things are worse than before. NetworkManager-0.9.8.0-1.fc18.x86_64 gnome-shell-3.6.3.1-1.fc18.x86_64
*** Bug 734681 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.