Bug 447213

I have the same problem with WPA2 (TKIP encryption), however I have not tried to
reproduce the problem with AES encryption.  My wireless card is the Intel®
Wireless WiFi Link 4965AGN and I am using the iwl4965-firmware package.  I am
unsure whether the NetworkManager package or the iwl4965-firmware package is to
blame.

When the connection is lost, trying to reconnect brings up the WPA password
dialog which shows a masked password that is very long and looks like it might
be the hex format of the previously entered password.  (I am not at my PC right
now to confirm that only hex characters are used).

Steps to reproduce:
1.  Connect to WPA2(TKIP) wireless network.
2.  Suspend or lose connection
3.  Try to reconnect
4.  I am prompted again with the WPA password dialog.

I am having very similar problems.  I am away from home (one of two usual WiFi
networks this computer usually uses) and I cannot get it to use the correct WPA
key.  I enter the correct key and it tries to login, fails, and then asks for
the key.  When it asks for the key, the field is already populated with an
incorrect key.  I cannot get it to accept the correct key.

Changing status to ASSIGNED

Cheers
Balaji

I am also experiencing very similar problems to the bug opener except
re-entering the correct password does not remedy the problem.

I use the Madwifi drivers with my Atheros chipset. My wireless security is WPA2
(AES), after a resume NetworkManager attempts to connect automatically but keeps
requesting the password, which when asked to show appears to be in hex form so
it's unrecognisable to me. However I re-enter it correctly to no avail. It
re-prompts me for the correct password. After awhile it makes wlan0 'inactive'.

I think this may possibly be a problem with NetworkManager not making a
distinction between WPA and WPA2 Personal (They're the same option) but WPA2
must be AES, whereas WPA can be either TKIP or AES.

Here is an output taken directly after startup:
[root@Jon-Laptop Jon]# tail /var/log/messages
Jun 24 03:26:40 Jon-Laptop NetworkManager: <info>  Activation (wlan0) Stage 4 of
5 (IP Configure Get) complete.
Jun 24 03:26:40 Jon-Laptop NetworkManager: <info>  Activation (wlan0) Stage 5 of
5 (IP Configure Commit) started...
Jun 24 03:26:40 Jon-Laptop avahi-daemon[2233]: Joining mDNS multicast group on
interface wlan0.IPv4 with address 192.168.1.100.
Jun 24 03:26:40 Jon-Laptop avahi-daemon[2233]: New relevant interface wlan0.IPv4
for mDNS.
Jun 24 03:26:40 Jon-Laptop avahi-daemon[2233]: Registering new address record
for 192.168.1.100 on wlan0.IPv4.
Jun 24 03:26:41 Jon-Laptop NetworkManager: <info>  (wlan0): device state change:
7 -> 8
Jun 24 03:26:41 Jon-Laptop NetworkManager: <info>  Policy set (wlan0) as default
device for routing and DNS.
Jun 24 03:26:41 Jon-Laptop NetworkManager: <info>  Activation (wlan0)
successful, device activated.
Jun 24 03:26:41 Jon-Laptop NetworkManager: <info>  Activation (wlan0) Stage 5 of
5 (IP Configure Commit) complete.
Jun 24 03:27:33 Jon-Laptop console-kit-daemon[1943]: WARNING: Couldn't read
/proc/2678/environ: Error reading file '/proc/2678/environ': No such process
[root@Jon-Laptop Jon]# 

And after resume (where bug occurs):
[root@Jon-Laptop Jon]# tail /var/log/messages
Jun 24 03:05:59 Jon-Laptop NetworkManager: <info>  Config: added 'group' value
'WEP40 WEP104 TKIP CCMP'
Jun 24 03:05:59 Jon-Laptop NetworkManager: <info>  Activation (wlan0) Stage 2 of
5 (Device Configure) complete.
Jun 24 03:05:59 Jon-Laptop NetworkManager: <info>  Config: set interface ap_scan
to 1
Jun 24 03:05:59 Jon-Laptop NetworkManager: <info>  (wlan0): supplicant
connection state change: 2 -> 0
Jun 24 03:05:59 Jon-Laptop NetworkManager: <info>  (wlan0): supplicant
connection state change: 0 -> 2
Jun 24 03:06:24 Jon-Laptop NetworkManager: <info>  Activation (wlan0/wireless):
association took too long.
Jun 24 03:06:24 Jon-Laptop NetworkManager: <info>  (wlan0): device state change:
5 -> 6
Jun 24 03:06:24 Jon-Laptop NetworkManager: <info>  Activation (wlan0/wireless):
asking for new secrets
Jun 24 03:06:24 Jon-Laptop NetworkManager: <info>  (wlan0): supplicant
connection state change: 2 -> 0
Jun 24 03:06:39 Jon-Laptop NetworkManager: <info>  wlan0: link timed out.
[root@Jon-Laptop Jon]# 

If I can give an other outputs please ask. 

Me too :-) I'm using WPA Preshared Key on my access point. NM fails to connect
and prompts me for a password, I enter it correctly (verified by having show
password enabled). NM then attempts to reconnect, fails, and the password in the
dialog box is random junk.

This is with NetworkManager-0.7.0-0.9.4.svn3675.fc9.i386

I've also raised the priority to Urgent.

Same Problem here, using using the iwl3945, until today I could at least
reconnect to the network when entering the correct passwort (everytime) but
since today it doesn't work anymore and I cant associate with the AP. 

Networkmanager is at neweset 0.7.0 version
Running Fedora 9 with all upgrades

Output in of /var/log/messages:


Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) starting
connection 'queens'
Jul  3 19:25:10 snoopy NetworkManager: <info>  (wlan0): device state change: 3 -> 4
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) scheduled...
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) started...
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) scheduled...
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) complete.
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) starting...
Jul  3 19:25:10 snoopy NetworkManager: <info>  (wlan0): device state change: 4 -> 5
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0/wireless):
access point 'queens' has security, but secrets are required.
Jul  3 19:25:10 snoopy NetworkManager: <info>  (wlan0): device state change: 5 -> 6
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) complete.
Jul  3 19:25:10 snoopy NetworkManager: Missing or invalid key management
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) scheduled...
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) started...
Jul  3 19:25:10 snoopy NetworkManager: <info>  (wlan0): device state change: 6 -> 4
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) scheduled...
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 1 of 5
(Device Prepare) complete.
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) starting...
Jul  3 19:25:10 snoopy NetworkManager: <info>  (wlan0): device state change: 4 -> 5
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0/wireless):
connection 'queens' has security, and secrets exist.  No new secrets needed.
Jul  3 19:25:10 snoopy NetworkManager: <info>  Config: added 'ssid' value 'queens'
Jul  3 19:25:10 snoopy NetworkManager: <info>  Config: added 'scan_ssid' value '1'
Jul  3 19:25:10 snoopy NetworkManager: <info>  Config: added 'key_mgmt' value
'WPA-PSK'
Jul  3 19:25:10 snoopy NetworkManager: <info>  Config: added 'psk' value '<omitted>'
Jul  3 19:25:10 snoopy NetworkManager: <info>  Config: added 'proto' value 'WPA RSN'
Jul  3 19:25:10 snoopy NetworkManager: <info>  Config: added 'pairwise' value
'TKIP CCMP'
Jul  3 19:25:10 snoopy NetworkManager: <info>  Config: added 'group' value
'WEP40 WEP104 TKIP CCMP'
Jul  3 19:25:10 snoopy NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) complete.
Jul  3 19:25:10 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 2 -> 0
Jul  3 19:25:10 snoopy NetworkManager: <info>  Config: set interface ap_scan to 1
Jul  3 19:25:10 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 0 -> 2
Jul  3 19:25:11 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 2 -> 3
Jul  3 19:25:11 snoopy kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Jul  3 19:25:11 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 3 -> 4
Jul  3 19:25:11 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 4 -> 5
Jul  3 19:25:11 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 5 -> 6
Jul  3 19:25:12 snoopy avahi-daemon[2205]: Registering new address record for
fe80::21b:77ff:fe54:44 on wlan0.*.
Jul  3 19:25:16 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 6 -> 0
Jul  3 19:25:16 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 0 -> 2
Jul  3 19:25:21 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 2 -> 0
Jul  3 19:25:21 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 0 -> 2
Jul  3 19:25:22 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 2 -> 3
Jul  3 19:25:22 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 3 -> 0
Jul  3 19:25:22 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 0 -> 4
Jul  3 19:25:22 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 4 -> 5
Jul  3 19:25:22 snoopy NetworkManager: <info>  (wlan0): supplicant connection
state change: 5 -> 6
Jul  3 19:25:25 snoopy NetworkManager: <info>  wlan0: link timed out.

I managed to solve this problem, with the help of johannlo from fedoraforum.org
- at least in my case, using the madwifi drivers.

Perhaps the workaround will work for you. You can find details in Bug 453124 .

This leads me to believe my bug report is a possible dupe of this one, that is,
if the solution works for you.

Didnt help me, i just realized i can't even associate after reboot ... so this
is a real problem, i tested it with a different Network Card (Linksys AirForce
One) and got the same error. (Output see last post) 

I forgot to mention, if it wasn't obvious, to replace 'ath_pci' in the file with
your appropriate driver.

Yeah I replaced it with the right one but it doesnt help ... still cant
associate with my WPA Encrypted AccessPoint using either the iwl3945 ... or the
Broadcom. 

Think mine actually belongs to another #Bug 453882 thanks for the help anyway

Here, just updated F8 to F9 (lots of problems in the middle) and I can't get it
to connect to my wifi AP (worked great with latest updates in F8).

One thing I noticed as was stated above in comment #6 is that after conexion
fails the password that appears isn't the one I entered, but it's not random as
was stated (don't know how it comes up, but it's always the same).

I also noticed that the same thing happens when running wpa_passphrase:

# wpa_passphrase myAP mypassword
network={
        ssid="myAP"
        #psk="mypassword"
        psk=15c861e9c395a6b501cd86a3ce18cac8effb5b30273286daa44a2d731a433f46
}

What's wrong here.

+1 here. I'm running iwl3945 as well, and until the last update (it seems) i
could connect no problem. Now, i can not. When i find anything else, I'll report
it. 

I've tried wep, wpa/wpa2 personal. Only way i can connect is without any
encryption. 

I'm also getting selinux errors now that i didn't get before. All relating to
/var/run/dhclient-wlan0.pid (unlink, read, getattr)

SELinux is preventing NetworkManager (NetworkManager_t) "unlink" to
./dhclient-wlan0.pid (var_run_t)

I'm experiencing the same with the last version: NetworkManager-0.7.0-0.11.svn4022.4.fc9.i386

I've got an intel 4965 AG and i'm using kernel 2.6.26.5-45.fc9.i686.

With the previous version i was able to connect after some voodoo, but now i can't no matter how i try.

The 50% of the updates of this package makes it to fail and the other 50% makes it work, almost most of the times. This is a true pain coming from the "Pain-Free Networking" for gnome desktop.

PD: Personally i think that the thing that shows in the password dialog is the hash of the password itself and that maybe nm is getting crazy and mixes the password from user input and the hashed password from the key storage.

Same problem with Atheros AR5418 card, ath9k driver, wpa_supplicant-0.6.4-2.fc10.x86_64 and NetworkManager-0.7.0-0.11.svn4229.fc10.x86_64. 
As #15 notes partial NM functionality returns/lost after each round of kernel update. 
Situation is pretty bad at the moment with 2.6.27.5-109.fc10.x86_64. I have seen all possible combination of this reconnection issue- but earlier sitting near the router and restarting the box would have given me the connection. But it is no more the case. in the past 5 reboots it could connect only once- so this problem is reproducible 80% of the time.

#cat /var/log/wpa_supplicant.log|grep completed
WPA: Key negotiation completed with 00:1b:11:62:a9:4a [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:1b:11:62:a9:4a completed (auth) [id=0 id_str=]
WPA: Group rekeying completed with 00:1b:11:62:a9:4a [GTK=CCMP]
WPA: Group rekeying completed with 00:1b:11:62:a9:4a [GTK=CCMP]
WPA: Key negotiation completed with 00:1b:11:62:a9:4a [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:1b:11:62:a9:4a completed (auth) [id=0 id_str=]
WPA: Key negotiation completed with 00:1b:11:62:a9:4a [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:1b:11:62:a9:4a completed (auth) [id=0 id_str=]
WPA: Key negotiation completed with 00:1b:11:62:a9:4a [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:1b:11:62:a9:4a completed (auth) [id=0 id_str=]
#cat cat  /var/log/wpa_supplicant.log|grep Disconnect
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys (goes on) 


#sudo cat  /var/log/wpa_supplicant.log|grep 'timed out'
Authentication with 00:1b:11:62:a9:4a timed out.(goes on)

# cat  /var/log/wpa_supplicant.log|grep 'timed out'|wc -l
40

# cat  /var/log/wpa_supplicant.log|grep Disconnect|wc -l
47
and finally  

# cat  /var/log/wpa_supplicant.log|grep completed|wc -l
10

Will be happy to be of any further assistance.
Deb

Just FYI, I'm not seeing this problem in F10.  I am not having the problem any more on the F9 laptop that is on my network.

(In reply to comment #17)
> Just FYI, I'm not seeing this problem in F10.  I am not having the problem any
> more on the F9 laptop that is on my network.

In your case it's probably that the drivers dont' suck anymore and that it's able to connect on the first try more often.  The issue where the applet shows you the _actual_ WEP/WPA hex key (instead of the passphrase or ASCII key you entered) is still present.

I just installed F10, and I have this same problem.  Actually, it's worse--even after re-typing the password in F10, I can't login, and it repeatedly shows me gibberish when I show the password.

As a workaround for the situation when it starts asking the password and shows you gibberish you can right click over NM applet -> edit connections and erase the entry for your current wifi connection, then to connect again with your password and it should work.

With f10 this have been working 100% of the time for me, but i have used it fewer times than with f9.

(In reply to comment #20)
> As a workaround for the situation when it starts asking the password and shows
> you gibberish you can right click over NM applet -> edit connections and erase
> the entry for your current wifi connection, then to connect again with your
> password and it should work.

Does not work for me. current kernel 2.6.27.7-130.fc10.x86_64. other configurations can be found in post #16.

The "gibberish" *is* your password, it's the Hexadecimal representation of it.  YOu can simply press Return (or hit OK) and you'll retry with the same password.

But there is something weird with that. Usually if you don't see the hex you have more chances of succeed connecting. When nm aks me my password showing the hex it keeps asking until i erase the profile and try to reconnect again, after that it accepts the password i give and works fine.

My wifi card is a 4965 AGN, but if it also happens with an atheros (posts #16 and #21) there is something that doesn't work in nm about hex.

I have the same problem on RHEL5.3 Beta with NetworkManager-0.7.0-0.11.svn4185.el5

Connection sometimes does work, then stops working

Duping this to the original bug about not remembering the passphrase.

If you have problems reconnecting when you just hit OK in the dialog that NM gives you when connections fail, that's a separate bug than this one describes.

*** This bug has been marked as a duplicate of bug 441070 ***