GNOME Bugzilla – Bug 670631
Keeps asking for wireless password
Last modified: 2014-01-23 20:19:12 UTC
Originally reported downstream in Launchpad: http://pad.lv/923737 This issue is actually both in NM and nm-applet -- what seems to happen is that despite NM gives up connecting to ask an agent for the password to a wireless network (if the password has changed or something), it doesn't turn down the link. Later, what seems like a rescan will trigger the last activated connection to be activated again, thus ending up asking for the password again... The result, an increasing number of auth dialogs for the same wireless network appear on screen. Relevant excerpt from syslog: Feb 22 13:24:48 selene NetworkManager[879]: <warn> No agents were available for this request. Feb 22 13:24:48 selene NetworkManager[879]: <info> (wlan0): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7] Feb 22 13:24:48 selene NetworkManager[879]: <warn> Activation (wlan0) failed for access point (rebirth_NET) Feb 22 13:24:48 selene NetworkManager[879]: <info> Marking connection 'rebirth_NET' invalid. Feb 22 13:24:48 selene NetworkManager[879]: <warn> Activation (wlan0) failed. Feb 22 13:24:48 selene NetworkManager[879]: <info> (wlan0): device state change: failed -> disconnected (reason 'none') [120 30 0] Feb 22 13:24:48 selene NetworkManager[879]: <info> (wlan0): deactivating device (reason 'none') [0] Feb 22 13:29:48 selene NetworkManager[879]: <info> Auto-activating connection 'rebirth_NET'. Feb 22 13:29:48 selene NetworkManager[879]: <info> Activation (wlan0) starting connection 'rebirth_NET' Feb 22 13:29:48 selene NetworkManager[879]: <info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Feb 22 13:29:48 selene NetworkManager[879]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Yeah, connections get failed for a short period of time and then retried after a while, like 5 minutes. The real fix here is to make NM smarter about asking for passwords, ie, make it ask for them less and just notify you that "hey your password may be wrong". I dont' think there's a problem with periodically attempting reconnection to a configured wifi network, but the failure case shouldn't be quite so in-your-face.
Isn't there some way that NM can distinguish between an authentication failure (hence the password might be wrong) and a general failure to connect (because of inability to talk to the AP)? There's a particular problem with the user interaction here: frequently, I find one of these password dialogs pops up when I'm already typing, and I type an unknown number of characters at the end of an already correct password. It's easy to mess up a stored password this way. It would seem to be more sensible to use a notification than a popup dialog, then the user can deal with it when they like (often, I don't care immediately that there are network problems, if I'm working on something offline).
As far as I know this is in fact fixed in git already. I'll double check myself in a little while but we can probably easily get the confirmation from Dan.
Great, thanks, I hope this means it lands in GNOME 3.8!
(In reply to comment #3) > As far as I know this is in fact fixed in git already.
If you're relying purely on comment #3 to close this bug, not so fast! The bug is certainly still present in network-manager 0.9.8.0.
Indeed, it's not fixed. I could confirm myself after I got a new report of the same issue popping up again; it's just harder for me to reproduce given that part of the code changed as per bug 665503. Reopening.
Created attachment 265726 [details] [review] don't reset retries after 5 min if the failure was because there were no secrets
(In reply to comment #8) > Created an attachment (id=265726) [details] [review] > don't reset retries after 5 min if the failure was because there were no > secrets ACK, this looks correct to me. Maybe we can reference the full URLs in the commit message? https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1224040 https://bugzilla.gnome.org/show_bug.cgi?id=670631 Also, the use of RESET_RETRIES_TIMESTAMP_TAG, FAILURE_REASON_TAG and RETRIES_TAG is a bit convoluted. Maybe we could cleanup all in a second patch.
(In reply to comment #9) > Also, the use of RESET_RETRIES_TIMESTAMP_TAG, FAILURE_REASON_TAG and > RETRIES_TAG is a bit convoluted. Maybe we could cleanup all in a second patch. see the danw/autoconnect branch
fixed in master