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 668251 - Passphrase lost after cancelling authentication
Passphrase lost after cancelling authentication
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: Wi-Fi
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-01-19 09:54 UTC by Milan Bouchet-Valat
Modified: 2020-11-12 14:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Bouchet-Valat 2012-01-19 09:54:27 UTC
(This is something another user raised in a GNOME Shell bug first:
https://bugzilla.gnome.org/show_bug.cgi?id=662338#c7)

I've WiFi problems here, and when the connection fails, I get the Shell authentication dialog, first pre-filled with the stored passphrase. So far, so good. I click cancel, I get the nm-applet auth dialog (the order doesn't seem to matter). This is bug 661208 or bug 662338, but these are different issues. The bug I'm reporting now is that, if I wait a few seconds, auth dialogs reappear, and they are both empty.

So:
1) Looks like cancelling authentication has an effect, but instead of preventing new automated connection, attempts it simply hides the passphrase. Actually, if I don't turn off the WiFi, the two auth dialogs will keep reappearing, with the empty passphrase entry.
2) The passphrase isn't really lost, because I can still see it in nm-connection-editor.
3) nm-applet and the Shell are both affected, so that's likely a bug in NM.

I also see a JS error from the Shell, I'm copying it here just in case there's a bug in the Shell (I'm CCing Giovanni):
   JS ERROR: !!!   Exception was: TypeError: apObj.item.updateAccessPoints is not a function
    JS ERROR: !!!     lineNumber = '1323'
    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:1323
"'
    JS ERROR: !!!     message = '"apObj.item.updateAccessPoints is not a function"'

Please just ask if you need debugging, the problem happens every 30 minutes. ;-)


This is with  NM 0.9.2 and gnome-shell 3.2.1 (Fedora 16).
Comment 1 Milan Bouchet-Valat 2012-01-19 10:10:35 UTC
A few precisions:
1) It doesn't happen all the time.
2) It actually happens after I remove and reload my WiFi card kernel module (brcmsmac), which is needed to work around a bug I have. This particular combination of events might trigger a problem that happens much more rarely in normal use.
Comment 2 Milan Bouchet-Valat 2012-01-19 10:55:28 UTC
OK, got it. When I reload my kernel module, the old connection isn't detected, and that's why I'm asked for the passphrase again. I can see that because if I enter the passphrase and click OK, a new connection is created for the WiFi network.

(BTW, this is now with the Shell 3.2.2, but I definitely think it's a NM bug.)
Comment 3 André Klapper 2012-05-04 11:30:35 UTC
Also see bug 665431, bug 665680
Comment 4 André Klapper 2020-11-12 14:34:40 UTC
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).