GNOME Bugzilla – Bug 372124
NM fails when AP auth method/password changes
Last modified: 2008-08-19 15:33:37 UTC
Tested on Ubuntu Edgy When the settings on the AP change, NM still tries the previous method of connection. This happens, for example, if the key or the encryption type of the AP changes (Actually tested going from WPA2 Personal to WPA Personal) The workaround to this problem was to manually start gnome-keyring-manager and manually delete the key to the wanted ESSID. After that, NM asked again for the method and password.
I also experienced this bug. I changed the WPA password on the AP. The NM tried to connect with the saved settings and didn't ask for the new settings when the current failed. I worked around the issue by going through the 'connect to other wireless network' option and inputing the new key.
*** Bug 447300 has been marked as a duplicate of this bug. ***
Confirming this bug, because similar issues were reported. Also, It happened to me when I applied an upgrade to my Access Point. The firmware upgrade was instructed to keep the settings. And after I checked them, it happened. However, it was not possible to connect the wireless machine with the AP anymore. The workaround was: 1. Disable the wireless in NM. 1. Remove the old setting from gconfd: $ gconftoold --recursive-unset /system/networking/wireless/networks/MY_NET 2. Enable the wireless in NM. 3. Select the network and enter the password. As additional information I must say the only field that changed in gconfd was wpa_psk_wpa_version, it changed from '2' to '4'. Well, and the timestamp also.
*** Bug 455737 has been marked as a duplicate of this bug. ***
*** Bug 341308 has been marked as a duplicate of this bug. ***
*** Bug 354162 has been marked as a duplicate of this bug. ***
A better w(In reply to comment #3) > [...] > The workaround was: > 1. Disable the wireless in NM. > 1. Remove the old setting from gconfd: > $ gconftoold --recursive-unset /system/networking/wireless/networks/MY_NET > 2. Enable the wireless in NM. > 3. Select the network and enter the password. shame on me. A better workaround is editing/deleting the network using the Network Manager Editor (nm-editor).
Yeah, if NM doesn't ask you again for the password, using the connection editor to update the connection is the right thing to do.
Using the nm-editor is just a workaround for something that a common user expect to be done automatically. Please, reconsider it at least as an usability bug.
I have to second Germán here.
By the way, the bug was added when there was no connection manager. At least now the workaround is easier. It's interesting to note that changing the encryption type and/or password in the connection manager won't fix the issue. Only deleting the entry and starting over will correctly configure the password. Still, as Germán said above, the bug continues.
Unfortunately, there's no good way to distinguish these cases from simple failures to connect. There are effectively two cases here: 1) Key changed, but other attributes stay the same. For WEP, failures to associate can be due to any number of issues, not just that the key changed. Drivers also suck. NM shouldn't be asking for the WEP key so often just because something failed to associate, NM should be trying a couple times. For WEP, users will simply have to update their key in the connection editor when the key changes because WEP just sucks. That's the way it is. For WPA, we can possibly be more intelligent here, but we need to make the failure modes of wpa_supplicant more exposed. The supplicant will just keep trying to connect to the AP over and over; we need to push the "your key is wrong" or "associated successfully but authentication failed" states back up to NetworkManager. 2) security attributes changed; for some cases (switch from PSK -> 802.1x) all your auth information is completely changed anyway, thus you'll need to re-enter a lot more information. NM should have handled the switch from WPA -> RSN OK though, and I'm pretty sure 0.7 will handle this better. The real problem is that there isn't enough information about failures conveyed up the stack from the drivers back up to the supplicant and then to NetworkManager. We need to fix this from the bottom up in the kernel and the supplicant before we can get NM to do anything intelligent about authentication failures. WEP is a completely lost cause, but we may be able to do something about WPA.
A simpler workaround (for the time being) would be to handle NM in two fronts or threads or whatever: 1) NM tries to connect for the first time. If it connects, fine. 2) If it doesn't, then it could display the whole config options (the usual dialog for setting up a new connection) for the AP, with last options used already selected, like password, security type, etc. In the background though, it can keep trying to connect to the AP with the old options. 3) If it's successful in the background process, it can simply hide the change config dialog. If the user presses OK without changing options, then it hides the window and continue the background connection trials. 4) If the user changes options, it can cancel the background connection trial and start another with the new options. At least that could solve the problems till something more clever can be found, though I think this would solve most problems.