Bug 447213 - networkmanager remembers password incorrectly
networkmanager remembers password incorrectly
Status: CLOSED DUPLICATE of bug 441070
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
high Severity urgent
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-18 16:52 EDT by Bryan Che
Modified: 2009-02-04 19:33 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-04 19:33:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bryan Che 2008-05-18 16:52:08 EDT
Description of problem:
Often times if I suspend my laptop or if NetworkManager loses network connection
and then tries to reconnect to my network, it remembers the password for the
network incorrectly.  For example, I use WPA for one of my networks.  When
NetworkManager tries to reconnect to it, it is unable and prompts me to enter
the password.  If I click to show the password that NetworkManager has, it is
jibberish and not correct.  If I then re-enter the correct password, then
NetworkManager can connect to the network again.


Version-Release number of selected component (if applicable):

NetworkManager-0.7.0-0.9.3.svn3623.fc9.x86_64


How reproducible:

Very


Steps to Reproduce:
1. Suspend laptop or lose network connection
2. try to reconnect to password-protected network
3.
  
Actual results:
NetworkManager has the wrong password and can't connect

Expected results:
NetworkMangaer has sthe correct password and connects.

Additional info:
Comment 1 Patrick Klingemann 2008-05-21 16:56:55 EDT
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.
Comment 2 eric@christensenplace.us 2008-05-25 09:08:27 EDT
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.
Comment 3 Balaji G 2008-06-06 07:32:21 EDT
Changing status to ASSIGNED

Cheers
Balaji
Comment 5 Jonathan Pritchard 2008-06-23 22:56:38 EDT
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. 
Comment 6 John Dennis 2008-07-02 13:11:02 EDT
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.
Comment 7 Philipp Fehre 2008-07-03 13:29:22 EDT
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.
Comment 8 Jonathan Pritchard 2008-07-03 14:16:35 EDT
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.
Comment 9 Philipp Fehre 2008-07-03 14:37:35 EDT
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) 

Comment 10 Jonathan Pritchard 2008-07-03 14:53:01 EDT
I forgot to mention, if it wasn't obvious, to replace 'ath_pci' in the file with
your appropriate driver.
Comment 11 Philipp Fehre 2008-07-03 15:26:27 EDT
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. 
Comment 12 Philipp Fehre 2008-07-03 20:26:13 EDT
Think mine actually belongs to another #Bug 453882 thanks for the help anyway
Comment 13 Martí­n Marqués 2008-07-12 18:19:32 EDT
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.
Comment 14 Chris Ward 2008-07-14 12:48:59 EDT
+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)
Comment 15 Miguel Angel Perez 2008-10-06 04:20:51 EDT
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.
Comment 16 Deb Mukherjee 2008-11-16 02:07:18 EST
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
Comment 17 eric@christensenplace.us 2008-11-26 09:18:19 EST
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.
Comment 18 Dan Williams 2008-11-26 10:51:23 EST
(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.
Comment 19 Bryan Che 2008-12-01 17:50:28 EST
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.
Comment 20 Miguel Angel Perez 2008-12-01 18:25:17 EST
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.
Comment 21 Deb Mukherjee 2008-12-05 08:17:20 EST
(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.
Comment 22 Dan Williams 2008-12-05 17:58:55 EST
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.
Comment 23 Miguel Angel Perez 2008-12-05 18:20:32 EST
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.
Comment 24 Frederik Bijlsma 2009-01-02 13:01:43 EST
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
Comment 25 Dan Williams 2009-02-04 19:33:30 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.