Bug 428571 - WPA Key Request
WPA Key Request
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
11
i386 Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
: 503126 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-13 10:50 EST by eric@christensenplace.us
Modified: 2010-06-10 01:29 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-10 01:29:21 EDT
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 eric@christensenplace.us 2008-01-13 10:50:34 EST
Description of problem:
Whenever I start my computer or bring my computer out of "sleep" mode it
properly attempts to connect to my wireless network at home.  This network is
protected using WPA2 encryption.  The key is already stored on the computer but
the nm-applet still asks for the key.  If I hit ESC the computer will then
disconnect from the network.  If I then click on the nm-applet and select the
wireless network it will immediately attempt to connect to the network and then
connect without asking for the key.  The computer was originally trying to
connect to the proper network.

Version-Release number of selected component (if applicable):
nm-applet version 0.7.0

How reproducible:
Restart the computer or bring the computer out of sleep mode to allow it to
automatically connect to the network.

Actual results:
The computer will not connect to the network automatically without asking for
the key.  If the network is manually selected it will connect without asking for
the key.

Expected results:
The computer should automatically associate and connect with the wireless
network and not ask for the key.

Additional info:
This is happening on multiple computers.
Comment 1 Russell Harrison 2008-01-18 09:06:53 EST
I'm also seeing this behavior
Comment 2 Dan Williams 2008-01-18 09:56:34 EST
A few questions...

1) is the AP you're connecting to "hidden", ie not broadcasting its SSID?

2) Is this happening on PowerPC-based machines only?

3) What kernel package version are you using?
   (run 'uname -a' from a terminal)

4) What NetworkManager package version are you using?
   (run 'rpm -q NetworkManager' from a terminal)

This _might_ be a duplicate of Bug 213088.  Depending on what NM version you
have, I might ask you to update to the latest testing version of NM from the
F8-updates-testing repository.
Comment 3 eric@christensenplace.us 2008-01-18 12:00:03 EST
(In reply to comment #2)
> 1) is the AP you're connecting to "hidden", ie not broadcasting its SSID?
No, it is transmitting the SSID.  When I hide it, the system won't see and thus
doesn't connect to the network.

> 2) Is this happening on PowerPC-based machines only?
?

> 3) What kernel package version are you using?
>    (run 'uname -a' from a terminal)
2.6.23.9-85.fc8


> 4) What NetworkManager package version are you using?
>    (run 'rpm -q NetworkManager' from a terminal)
NetworkManager-0.7.0-0.6.6.svn3138.fc8

 
> This _might_ be a duplicate of Bug 213088.  Depending on what NM version you
> have, I might ask you to update to the latest testing version of NM from the
> F8-updates-testing repository.

I don't think this is a duplicate of Bug 213088.  The symptoms appear different.
Comment 4 Kevin R. Page 2008-01-27 17:47:40 EST
"Me too!"

(In reply to comment #2)
> A few questions...
> 1) is the AP you're connecting to "hidden", ie not broadcasting its SSID?

Not hidden, though it is a OpenWRT derivative broadcasting two SSIDs (one open
and one WPA2 - it's a FON box)
 
> 2) Is this happening on PowerPC-based machines only?

x86 here.
 
> 3) What kernel package version are you using?
>    (run 'uname -a' from a terminal)

kernel-2.6.23.14-107.fc8

> 4) What NetworkManager package version are you using?
>    (run 'rpm -q NetworkManager' from a terminal)

NetworkManager-0.7.0-0.6.7.svn3204.fc8

> This _might_ be a duplicate of Bug 213088.  Depending on what NM version you
> have, I might ask you to update to the latest testing version of NM from the
> F8-updates-testing repository.

This is iwl3945, which would seem to rule out bug #213088?
Comment 5 Kevin R. Page 2008-06-20 06:38:35 EDT
I'm still seeing this on F9.

NetworkManager-0.7.0-0.9.4.svn3675.fc9.i386
wpa_supplicant-0.6.3-5.fc9.i386
kernel-2.6.25.6-55.fc9.i686

using iwl3945 (on a ThinkPad X61s) to connect to a WPA2-PSK (AES) encrypted
network. *Sometimes* it connects, so the stored key is ok - but most of the time
it fails and asks for the key again.

Is this a familiar/known issue? I haven't managed to spot the pattern as to when
and when it doesn't work - any thoughts on narrowing it down?

It might not be Fedora specific?
http://forums.opensuse.org/archives/novell-archives/309414-wpa-wpa2-leap-networkmanager.html
Comment 6 Dan Williams 2008-10-20 11:29:10 EDT
Is this still an issue with latest kernel, supplicant, and NM?  Please re-open if it is!

WPA/WPA2-PSK tested successfully with 2.6.26.5-28.fc8, NM svn4022.4, wpa_supplicant 0.5.10-6.fc8, against a Linksys WRT54GC.
Comment 7 Kevin R. Page 2008-10-20 17:17:52 EDT
Still a problem - if anything it got progressively worse from when first reported (fewer and fewer connections were successful) such that it became unusable - so I gave up even trying to use it.

I've tried again tonight, and there hasn't been a single successful connection.

kernel-2.6.26.5-45.fc9.i686
wpa_supplicant-0.6.3-6.fc9.i386
NetworkManager-0.7.0-0.11.svn4022.4.fc9.i386

WPA2-PSK (AES), iwl3945.

A Nokia 770 connects to the AP fine.

More than happy to collect debug to get to the bottom of this - just let me know what you need.
Comment 8 eric@christensenplace.us 2008-10-20 19:35:26 EDT
Yeah, I'm still seeing this issue.
Comment 9 Bug Zapper 2008-11-25 21:04:51 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Dan Williams 2009-02-04 19:14:28 EST
kernel/drivers and NM are more stable now, does this happen with latest NM updates?  If so, which specific version of NM and the kernel?
Comment 11 Kevin R. Page 2009-02-09 02:30:16 EST
No luck with kernel-2.6.27.9-159.fc10.i686

However kernel-2.6.28.1-9.rc2.fc10.i686 (testing for bug #470225) is giving much better results. It seems to reliably connect to the WPA2 network on boot. I don't have much experience leaving/re-joining the network - I think I've seen it fail in this case, but haven't tested this scenario much, and obviously there are other problems with the driver (bug #470225) which could be getting mixed up here. I'll keep an eye on it.

NetworkManager-0.7.0-1.git20090102.fc10.i386
Comment 12 Kevin R. Page 2009-02-09 15:10:13 EST
Spoke too soon - wouldn't bind to the WPA network today, either on boot or when selected manually in NM. 2.6.28.1-9.rc2.fc10.i686. It tries to connect for a while, then times out prompting for the WPA passphrase (already filled in); hitting connect again tries, timeouts, brings up passphrase dialog etc.

Logs show:
Feb  9 18:40:07 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  disconnected -> scanning
Feb  9 18:40:08 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  scanning -> associating
Feb  9 18:40:22 mopp NetworkManager: <info>  wlan0: link timed out.
Feb  9 18:40:28 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  associating -> disconnected 
Feb  9 18:40:28 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  disconnected -> scanning
Feb  9 18:40:29 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  scanning -> associating
Feb  9 18:40:32 mopp NetworkManager: <info>  Activation (wlan0/wireless): association took too long.
Feb  9 18:40:32 mopp NetworkManager: <info>  (wlan0): device state change: 5 -> 6
Feb  9 18:40:32 mopp NetworkManager: <info>  Activation (wlan0/wireless): asking for new secrets
Feb  9 18:40:32 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  associating -> disconnected
Comment 13 Kevin R. Page 2009-03-29 10:06:18 EDT
Still experiencing the same problem. Successfully connected once yesterday (which surprised me!), but has failed each time since.

kernel-2.6.29-3.fc10.i686
NetworkManager-0.7.0.99-5.git20090326.fc10.i386
wpa_supplicant-0.6.4-3.fc10.i386
Comment 14 Kevin R. Page 2009-04-11 18:51:20 EDT
With 2.6.29-3.fc10.i686 I seems to be getting a connection more frequently (perhaps as often as 1 in 4).

Please let me know where I should collect debug to compare (without any package changes if sometimes works, sometimes doesn't. I'd like to try and pinpoint what changes).

If I were to hazard a guess at a pattern, I seem to get a connection more reliably when I'm resuming the laptop from suspend(!).
Comment 15 Kevin R. Page 2009-04-18 07:52:42 EDT
My sample size is still a bit small, but I think I can qualify comment #14 a little.

I seem to have greater success getting a WPA2 connection (possibly 100% - I'm paying attention to these cases not) if:

1) after boot, the laptop is left at the GDM screen for a number of minutes (at least 5?). When I log in to GDM, the connection comes up very quickly.

2) if the laptop is brought out of suspend when it was booted in a different location away from the WPA2 network in question (possibly at a location where it was associated with a different wireless network)

I wonder whether it's something to do with the list of wireless networks NM/wpa_supplicant has available? Perhaps immediately at boot it's not up to date? The AP in question advertised two SSIDs, once WPA2 the other open.

1a) if I log in to GDM immediately, NM fails to associated, then I log out, wait 5 minutes, NM still fails to associate.


Please let me know where to look to compare the success and fail cases.
Comment 16 eric@christensenplace.us 2009-06-22 23:03:31 EDT
I'm still seeing this in F11 but only when my laptop is coming out of being suspend mode.
Comment 17 Dan Williams 2009-10-16 18:56:21 EDT
What wifi hardware, and what kernel versions are people using?  Most of the time this is a result of the driver or device not being quite ready when it says its ready, which probably means the first scan is failing and then the supplicant times out.
Comment 18 Kevin R. Page 2009-10-19 09:42:34 EDT
(In reply to comment #17)
> What wifi hardware, and what kernel versions are people using?

I've not experienced this issue with non-suspend use since, I suspect, moving to 2.6.30. Thinkpad X61s, 3945ABG, 2.6.30.8-64.fc11.i686.

Coming out of suspend - which I use infrequently - has definitely sometimes worked. Suspend throws up other issues on this laptop which may be the root of when it doesn't work, so I wouldn't want to authoritatively say if it's fixed or not for suspend.
Comment 19 Dan Williams 2009-11-11 11:14:42 EST
Ok, if people see this again, here's what we do...

1) Look in /var/log/messages.  If the supplicant state bounces back and forth between disconnected and scanning, but never connects and then the NM connection times out, then that's the same issue as this bug.

2) if you pick it manually and NM still won't connect, then try running "iwlist wlan0 scan" in a root shell, and look for your AP in the list.  If you don't find it, then we might have a driver problem.  If you do see it, then try to connect to it from NM again and report whether or not that works.

I think the problem here is that the driver/card is just not finding the AP within the first 1 or two scans after resume.
Comment 20 Dan Williams 2009-11-11 12:47:26 EST
*** Bug 503126 has been marked as a duplicate of this bug. ***
Comment 21 eric@christensenplace.us 2009-11-11 13:04:56 EST
I'm not seeing this on F12 and on the one laptop that is on F11 it only asks after coming out of sleep.  It's not nearly as annoying as it use to be.
Comment 22 Dan Williams 2009-11-13 18:43:22 EST
Ok, even after sleep when it asks, it would be interesting to see /var/log/messages.
Comment 23 Bug Zapper 2009-11-18 07:24:46 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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 24 Bug Zapper 2010-04-27 07:52:56 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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 25 Dan Williams 2010-06-10 01:29:21 EDT
Closign due to lack of response; if this happens on F12 at all, please re-open.  Thanks!

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