Bug 444051

Summary: NetworkManager does not reliably remember passphrase on Intel 3945 and Fedora 9 Preview, x86_64
Product: [Fedora] Fedora Reporter: Scott Clark <probiscus12>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: adi1981.2k5, dcbw, gvarisco, jns, orion, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-14 17:52:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log/messages output after trying to connect to AirOrangeX
none
dmesg output
none
lspci -nn -vvv output
none
/var/log/messages grepped for NetworkManager
none
iwlist output from right after connecting. none

Description Scott Clark 2008-04-24 19:09:22 UTC 
Description of problem:
First of all, I regularly connect to two WPA-secured networks. One is my home,
WPA-PSK wireless network. The other is my university network, which is WPA-EAP
(TKIP PEAP MSCHAPv2). NetworkManager in Fedora 9 is capable of connecting to
both of them succesfully, and usually does so the first time they are set up.
NetworkManager seems to store the passphrases successfully, since it will
occasionally connect fine without needing (or asking for) credentials/wireless
network info. However, more often than not, I am asked for a password that I
have previously entered, and then after that NetworkManager fails to connect or
asks for the passphrase again, putting me in an endless loop. Restarting the
networkmanager service seems to sometimes solve this problem, by allowing me to
connect, but not always. This happens on both WPA networks.

Version-Release number of selected component (if applicable):
kernel-2.6.25-1.fc9.x86_64
NetworkManager-0.7.0-0.9.2.svn3566.fc9.x86_64
NetworkManager-gnome-0.7.0-0.9.2.svn3566.fc9.x86_64

How reproducible:
This happens about 80 - 90% of the times I try to connect with F9 preview. It
typically happens more often when I am re-connecting (i.e. after resuming from
suspend, or after I disable wireless or after the connection drops)

Steps to Reproduce:
1. Have an Intel 3945 wireless card (I think it may be specific to this card)
2. Run F9 Preview and connect to multiple WPA networks
3. Restart the computer, then allow Networkmanager to attempt to connect on its
own, and have mixed results.
4. Try suspending, or disabling the wireless, or connecting to a different
network, or go out of range and come back.
5. resume or re-enable or come back in range and allow networkmanager to attempt
to re connect.
5. Get message asking for information that was already entered, enter it, then
watch it most likely fail to connect or ask for that info again.

Expected results:
After connecting to a wireless network and entering the network details (wpa
style, auth, inner auth, username/password, etc) for the first time and pressing
connect, I can then connect to that network in the future with out ever seeing
the network details box again.

Additional info:
Also see bug 413781 and other network manager bugs relating to the 3945.
Also, when the network details/secrets dialog comes up after entering the
passphrase once, the password box has dots as if it has a password saved, but
the connect button is not available until I re enter the passphrase
Comment 1 Scott Clark 2008-04-24 19:09:23 UTC 
Created attachment 303675 [details]
/var/log/messages output after trying to connect to AirOrangeX
Comment 2 Scott Clark 2008-04-24 19:12:16 UTC 
Created attachment 303676 [details]
dmesg output
Comment 3 Scott Clark 2008-04-24 19:13:06 UTC 
Created attachment 303677 [details]
lspci -nn -vvv output
Comment 4 Scott Clark 2008-04-24 19:20:57 UTC 
My home WPA-PSK network is named "My House" and the schools WPA-EAP network is
"AirOrangeX", while the school also has a non secured network name "AirOrange"
Comment 5 Adrian "Adi1981" P. 2008-05-01 10:42:21 UTC 
I've got the same issue, it's still asking for passphrase. Providing correct
passphrase leads to another question about passphrase. It's starting to be
really frustrating. Today i was trying to connect over 30 minutes until i've
successfully connected to network. Meantime i had to restart my laptp about 10
times, because NM was refusing to find my network (but he saw few other networks
from my flat) and/or was still asking about passphrase. Restarting NM doesn't
helped. And all was caused by one stupid disconnect from network, to which i've
been connected since few last days. Maybe this log will be usefull to trace this
issue.

# NetworkManager --no-daemon
NetworkManager: <info>  starting...
RTNETLINK answers: File exists
NetworkManager: <info>  Found radio killswitch
/org/freedesktop/Hal/devices/ipw_wlan_switch
NetworkManager: <info>  eth0: Device is fully-supported using driver 'atl1'.
NetworkManager: <info>  Found new Ethernet device 'eth0'.
NetworkManager: <info>  (eth0): exported as
/org/freedesktop/Hal/devices/net_00_1d_60_cd_5d_be
NetworkManager: <info>  wlan0: Device is fully-supported using driver 'iwl4965'.
NetworkManager: <info>  wlan0: driver supports SSID scans (scan_capa 0x01).
NetworkManager: <info>  Found new wireless (802.11) device 'wlan0'.
NetworkManager: <info>  (wlan0): exported as
/org/freedesktop/Hal/devices/net_00_13_e8_bc_9c_6b
NetworkManager: <info>  (eth0): device state change: 1 -> 2
NetworkManager: <info>  Bringing up device eth0
NetworkManager: <info>  Deactivating device eth0.
Nothing to flush.
Nothing to flush.
NetworkManager: <info>  (wlan0): device state change: 1 -> 2
NetworkManager: <info>  Bringing up device wlan0
NetworkManager: <info>  Deactivating device wlan0.
Nothing to flush.
Nothing to flush.
NetworkManager: <info>  (wlan0): device state change: 2 -> 3
NetworkManager: <info>  (wlan0) supplicant interface is now in state 2 (from 1).
NetworkManager: <WARN>  killswitch_getpower_reply(): Error getting killswitch
power: hal-ipw-killswitch-linux returned 255.
NetworkManager: <info>  Activation (wlan0) starting connection 'Auto tvksmp_3062'
NetworkManager: <info>  (wlan0): device state change: 3 -> 4
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare)
scheduled...
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure)
scheduled...
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure)
starting...
NetworkManager: <info>  (wlan0): device state change: 4 -> 5
NetworkManager: <info>  Activation (wlan0/wireless): access point 'Auto
tvksmp_3062' has security, but secrets are required.
NetworkManager: <info>  (wlan0): device state change: 5 -> 6
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
NetworkManager: Missing or invalid key management
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare)
scheduled...
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <info>  (wlan0): device state change: 6 -> 4
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure)
scheduled...
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure)
starting...
NetworkManager: <info>  (wlan0): device state change: 4 -> 5
NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto
tvksmp_3062' has security, and secrets exist.  No new secrets needed.
NetworkManager: <info>  Config: added 'ssid' value 'tvksmp_3062'
NetworkManager: <info>  Config: added 'scan_ssid' value '1'
NetworkManager: <info>  Config: added 'key_mgmt' value 'WPA-PSK'
NetworkManager: <info>  Config: added 'psk' value '<omitted>'
NetworkManager: <info>  Config: added 'proto' value 'WPA'
NetworkManager: <info>  Config: added 'pairwise' value 'TKIP'
NetworkManager: <info>  Config: added 'group' value 'TKIP'
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 0
NetworkManager: <info>  Config: set interface ap_scan to 1
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 3
NetworkManager: <info>  (wlan0) Supplicant interface state change: 3 -> 4
NetworkManager: <info>  (wlan0) Supplicant interface state change: 4 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 4
NetworkManager: <info>  (wlan0) Supplicant interface state change: 4 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 4
NetworkManager: <info>  wlan0: link timed out.
NetworkManager: <info>  (wlan0) Supplicant interface state change: 4 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 4
NetworkManager: <info>  (wlan0) Supplicant interface state change: 4 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 4
NetworkManager: <info>  Activation (wlan0/wireless): association took too long.
NetworkManager: <info>  (wlan0): device state change: 5 -> 6
NetworkManager: <info>  Activation (wlan0/wireless): asking for new secrets
NetworkManager: <info>  (wlan0) Supplicant interface state change: 4 -> 0
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 0
NetworkManager: <info>  wlan0: link timed out.
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare)
scheduled...
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <info>  (wlan0): device state change: 6 -> 4
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure)
scheduled...
NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure)
starting...
NetworkManager: <info>  (wlan0): device state change: 4 -> 5
NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto
tvksmp_3062' has security, and secrets exist.  No new secrets needed.
NetworkManager: <info>  Config: added 'ssid' value 'tvksmp_3062'
NetworkManager: <info>  Config: added 'scan_ssid' value '1'
NetworkManager: <info>  Config: added 'key_mgmt' value 'WPA-PSK'
NetworkManager: <info>  Config: added 'psk' value '<omitted>'
NetworkManager: <info>  Config: added 'proto' value 'WPA RSN'
NetworkManager: <info>  Config: added 'pairwise' value 'TKIP CCMP'
NetworkManager: <info>  Config: added 'group' value 'WEP40 WEP104 TKIP CCMP'
NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
NetworkManager: <info>  Config: set interface ap_scan to 1
NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
NetworkManager: <info>  Activation (wlan0/wireless): association took too long.
NetworkManager: <info>  (wlan0): device state change: 5 -> 6
NetworkManager: <info>  Activation (wlan0/wireless): asking for new secrets
NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 0
NetworkManager: <WARN>  get_secrets_cb(): Couldn't get connection secrets:
applet-device-wireless.c.1298 (get_secrets_dialog_response_cb): canceled.
NetworkManager: <info>  (wlan0): device state change: 6 -> 9
NetworkManager: <info>  Activation (wlan0) failed for access point (tvksmp_3062)
NetworkManager: <info>  Marking connection 'Auto tvksmp_3062' invalid.
NetworkManager: <info>  Activation (wlan0) failed.
NetworkManager: <info>  (wlan0): device state change: 9 -> 3
NetworkManager: <info>  Deactivating device wlan0.
Nothing to flush.
Nothing to flush.
^C
Comment 6 Dan Williams 2008-05-01 10:58:03 UTC 
Adrian: what's the output of '/sbin/iwlist wlan0 scan' from a terminal (as root)
for your AP?  Feel free to remove the BSSID of the AP if you like.
Comment 7 Adrian "Adi1981" P. 2008-05-01 11:42:34 UTC 
For now it gives me those 2 networks (first is mine). NM found 3 networks.
Although now i'm connected, so i think it'll be more helpful if i will try to
scan networks when there'll be some problems with connection. I will disconnect
later and will try again. It's also possible that the problem is with driver in
kernel, if i remember good on earlier kernels there was no problems with
scanning, so i will try also with some earlier 2.6.25 git kernel.

wlan0     Scan completed :
          Cell 01 - Address: 00:xx:yy:zz:9F:E2
                    ESSID:"tvksmp_3062"
                    Mode:Master
                    Frequency:2.462 GHz (Channel 11)
                    Channel:11
                    Quality=65/100  Signal level=-59 dBm  Noise level=-85 dBm
                    Encryption key:on
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:tsf=00000000e618cdf9
          Cell 02 - Address: 00:0E:2E:C9:53:E8
                    ESSID:"tvksmp_2545"
                    Mode:Master
                    Frequency:2.462 GHz (Channel 11)
                    Channel:11
                    Quality=37/100  Signal level=-87 dBm  Noise level=-127 dBm
                    Encryption key:on
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:tsf=000001a28a9b419b
Comment 8 Scott Clark 2008-05-08 23:29:33 UTC 
Created attachment 304911 [details]
/var/log/messages grepped for NetworkManager

This is the grepped output of /var/log/messages after a boot up. I received
three password prompts, canceled the third, then selected the network from the
drop down list and it connected fine. Please let me know if it is better to
post these things as attachments or in a comment on the bug page.
Comment 9 Scott Clark 2008-05-08 23:37:27 UTC 
Created attachment 304913 [details]
iwlist output from right after connecting.

This is the output of "iwlist wlan0 scan" from right after NetworkManager
finally successfully connected. NetworkManager tried auto connecting, and asked
me for a password twice, that password of course had already been entered and
saved. I then hit cancel on the third prompt, and selected "My House" from the
nm-applet drop down, and it then connected just fine. At no point during that
procedure did I enter a password. The output of /var/log/messages is also
posted as an attachment. Please let me know if I should be posting this output
here in the body of a bugzilla comment, or as an attachment, I would like to do
this the right way! Also, I am running a completely updated (as of 7:30pm u.s.
est 05/08/09) Fedora 9 preview install, which is now i386, not x86_64 which is
what I was using when I first filed the bug. Let me know if you need more info!
Comment 10 Bug Zapper 2008-05-14 10:06:37 UTC 
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Gianluca Varisco 2008-09-05 09:35:22 UTC 
Scott,

Do you still have the problems you reported, even with the last F9-updates? Please let me know.
Comment 12 Orion Poplawski 2008-10-13 21:40:11 UTC 
One of our users is seeing very similar behavior with:

kernel-2.6.26.5-45.fc9.x86_64
NetworkManager-0.7.0-0.11.svn4022.4.fc9.x86_64

and iwl4965.
Comment 13 Scott Clark 2008-11-15 18:10:35 UTC 
Hi, sorry it took me a while to respond. I have graduated and moved on since filing this bug, so I can no longer test on the network at school. I can tell you that when I first filed this bug, there were similar bugs filed at the same time, 443595, 443288, 447213 and 413781 seem like they may very well have been the same bug or are very similar at least. Hopefully that may help you gather information or do bugzilla housekeeping at least. Sorry I can't be of more help but I can say that I am now using an open wireless network on a completely updated Fedora 9 system on a daily basis with no problems whatsoever, which I greatly appreciate!
Comment 14 Jessica Sterling 2009-03-05 15:38:12 UTC 
This bug has been triaged

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 15 Bug Zapper 2009-06-10 00:25:10 UTC 
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2009-07-14 17:52:14 UTC 
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.