[Gutsy] Unable to connect to Access Point if encryption method (WEP/WAP/WAP2) of the AP is changed

I believe a similar thing happened to me when I changed from using WEP to WPA on my access point.

confirmed.

previously success connecting via WPA. Now, when I switch from "WPA (TKIP)" to "WPA2 (CCMP)" on my router (AVM FRITZ!Box) network-manager wouldn't connect any longer. Also, signal strength goes down to zero (shown by Network Monitor applet). When I run the router in mixed mode (both WPA & WPA2) network-manager will only connect with WPA(1).

TKIP -> CCMP. Output from iwevent:
22:58:12.222225 wlan0 New Access Point/Cell address:Not-Associated
22:58:33.244050 wlan0 Set Encryption key:off
22:58:37.007310 wlan0 Set Mode:Managed

CCMP -> TKIP (switched back). iwevent reports New Access Point/Cell and Network Monitor applet showes good signal strength. But only after sudo /etc/dbus-1/event.d/25NetworkManager restart will network-manager reconnect via wlan0.

On CCMP iwlist scan reports:
IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK

and on TKIP iwlist scan reports:
IE: WPA Version 1
                        Group Cipher : WEP-40
                        Pairwise Ciphers (1) : WEP-40
                        Authentication Suites (1) : PSK

Searching for wireless in gconf-editor wouldn't show any results so I couldn't test the above.

I should add:
$ apt-cache show gnome-system-tools | grep Version
Version: 2.20.0-0ubuntu1
$ apt-cache show gconf-editor | grep Version
Version: 2.20.0-0ubuntu1

Seems more applicable to nm-applet since it is responsible for managing the keys.

The bug also can be demonstrated by connecting to a wireless network in WPA-Personal auth mode, then changing at a later time to WPA2-Personal ( knowingly incorrect). I then tried to change back to WPA-Personal however it would never release the old settings for that essid.

This is pretty much the same bug... however it doesn't even require any modification of the router settings. I would consider this a pretty serious issue especially considering gutsy is being sold on the basis of the excellent wireless support.

I can confirm this on Hardy alpha-2. It's a pain. I changed my AP (running dd-wrt) from WPA2 Personal to WPA Personal (but left the key the same) and neither Gutsy nor Hardy alpha 2 could associate until I went through nm-applet Connect to Other Wireless Network and entered the correct details. Surely the security protocol should be queried and updated on each scan or attempt to associate?

I am trying to verify if I am seeing the same problem or not as reported in this bug. I used to have a network using WEP, but then I changed to WPA-PSK and the connection stopped working. I have, however, found that I can connect to the network by choosing "Connect to other wireless network..." and entering the connection information by hand each time I want to connect. This works fine, but is quite annoying. So far this seems like the same bug as others are having (assuming that "Connect to other wireless network..." works for everyone else as well).

However, I have tried several times completely deleting the existing configuration for that network from gconf (either via the configuration editor or by deleting the corresponding directory in .gconf/system/networking/wireless/networks) and from my keyring (using the Keyring Manager). After a reboot, this makes nm-applet request key information as if it had never heard of the network, so as far as I can tell all old key information should be gone. After entering the key, the connection fails as before with the following message in /var/log/messages:

Jan 11 10:42:34 localhost NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 key_mgmt WPA-PSK'
Jan 11 10:42:34 localhost NetworkManager: <info> SUP: response was 'OK'
Jan 11 10:42:34 localhost NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 psk <key>'
Jan 11 10:42:34 localhost NetworkManager: <info> SUP: response was 'FAIL'
Jan 11 10:42:34 localhost NetworkManager: <WARN> nm_utils_supplicant_request_with_check(): real_write_supplicant_config: supplicant error for 'SET_NETWORK 0 psk <key>'. Response: 'FAIL'

Therefore, it is having problems with the key. I can still connect by choosing to "Connect to other wireless network...".

Unless somewhere I have not thought of there is some residual key information for this connection, this doesn't seem like it is a bug related to my prior WEP configuration. Perhaps this is a separate bug? Are others having the same experience? Can someone duplicate the steps I have taken and see if that solves the problem or not?

If others are having the same experience, then could it be that gconf or nm-applet are incorrectly storing the key information in the keyring or gconf and that is the problem? In this case, the fact that people are changing from one security protocol to another would just be coincidental and the real problem would apply generally to all WPA networks. Is this possible?

Please follow these instructions to install and use wicd (wifi network manager):

http://wicd.sourceforge.net/download.php

Please let us know if wifi and WPA2 encryption works better using wicd

Do I need to uninstall NetworkManager first?

Hi,

We are not in the M$ Windows world. No need to do the manual uninstall, install monkey business ;-)

First make sure that you first add the following line to /etc/apt/sources.list:
deb http://apt.wicd.net <ubuntu version> extras
where <ubuntu version> is your version of Ubuntu in lowercase (dapper, edgy, feisty, gutsy, hardy).

Then run the following commands:

sudo aptitude update
sudo aptitude install wicd

Doing this should automatically remove networkmanager and then install wicd

Regards,

Mark

So I gave wicd a try and it definitely didn't fix the problem. If anything, I had more trouble getting wicd working than network-manager. Network-manager's behavior is very consistent - it doesn't work when it automatically tries to connect to the network, it does when I choose "Connect to other wirless network..." and manually enter the ESSID and WPA password. When I selected the network in wicd, it would say "Obtaining IP address" for a while and then fail. It never asked for a password or network key, though it did recognize it as a WPA network. I tried changing the WPASupplicant driver in the preferences to a few different choices and that had no effect. There was no real option to manually configure the connection, so I didn't try that. Connecting to unsecured wireless networks did eventually work, but in general wicd was less responsive than network-manager. I even had to coax it to connect with a wired connection (which I used to reinstall network-manager).

I am having the problem too. It manifests in the form described by David; when i connect to my WPA2 network for the first time (after purging the essid from gconf), I enter the key and connect.
Any subsequent attempt fails with

NetworkManager: <WARN> nm_utils_supplicant_request_with_check(): real_write_supplicant_config: supplicant error for 'SET_NETWORK 0 psk <key>'. Response: 'FAIL'

I run the router in mixed mode WPA/WPA2.

Same problem here on an Asus F8 with an intel wireless 4965. Tried all the above methods but wouldn't work. It's a fresh hardy install.

Same problem here. It exists at least since 7.10.

I have configured a manual WiFi of a WPA2-only network. Works like a charm. Until I reboot. Then nm-applet "forgot" that the key was WPA2 and contains settings for WPA. Of course, it cannot connect to the router with those.

Select manual configuration. Type password. Fix settings. Peace until next reboot.

Note that the fix described in the first email of this bug does _not_ work: gconf-editor does not have an entry system > networking.

please test with NM 0.7 in intrepid (ubuntu 8.10).

 We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!