Bug 646376 – No prompt for networking secrets when existing wrong

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 646376 - No prompt for networking secrets when existing wrong


Summary:	No prompt for networking secrets when existing wrong


Status:	RESOLVED NOTGNOME

Product:	gnome-shell
Classification:	Core
Component:	network-indicator
Version:	unspecified
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	---
Assigned To:	gnome-shell-maint
QA Contact:	gnome-shell-maint

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2011-03-31 20:19 UTC by Owen Taylor
Modified:	2011-03-31 23:23 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Owen Taylor 2011-03-31 20:19:53 UTC

I think this is one bug, it might be three. It seems that once NetworkManager *thinks* it has secrets for a connection, you are never reprompted. Three manifestations:

 - If the encrpytion password changes for a WEP network, you stick forever in the "connecting" stage and never are prompted for a new password.

 - If you cancel out of the password dialog for a WEP network, you are never reprompted (reported by Jon McCann, haven't tried myself)

 - With a VPN network that requires one-time passwords, once you've connected, and disconnect, you won't be prompted for the new password on further connection attempts, which will just fail. Restarting NetworkManager works around.

Comment 1 Giovanni Campagna 2011-03-31 20:25:00 UTC

I think that all of this must be reassigned to NetworkManager and nm-applet, as currently the shell has no business in managing network secrets.

Comment 2 Owen Taylor 2011-03-31 21:10:47 UTC

I'd rather keep this open to track the issue until it gets fixed even if the actual bug is elsewhere.

Comment 3 Owen Taylor 2011-03-31 23:23:24 UTC

Discussed this with dcbw and he says it's something he fixed upstream and in NetworkManager-0.8.997-7.git20110330.fc15 - testing tentatively seems to confirm that.