Red Hat Bugzilla – Bug 449754
Doesn't connect to AP - incorrect ESSID being used?
Last modified: 2009-06-10 02:16:14 EDT
Description of problem:
On boot or resume, most of the time (but not always), my laptop fails to
correctly associate to the AP.
I'm not sure when this broke. It worked once after I upgraded to F9 (just after
release, and with a patched kernel for bug 439249), but then I was on holiday
for two weeks, and since it doesn't break all of the time that may not mean
much. I don't know what NM version I was using at the time - whatever was
current as of the 0-day updates, I guess.
I don't know if this is a kernel thing or NM. the tons of iwevent possibly make
it a kernel issue, but when I set the ESSID manually it all works fine, and NM
should be doing that, so....
Is there some way I can get NM to trace what it thinks its doing?
Version-Release number of selected component (if applicable):
kernel-2.6.25-14.bb.fc9.x86_64 (has a revert patch from bug 439249)
Most of the time, but not always
Steps to Reproduce:
1. Boot/resume laptop
2. NM should try to connect to ssid 'AGSM2'
iwevent shows tons (several per second) of:
wlan0 New Access Point/Cell address:Not-Associated
dmesg has tons of:
wlan0: RX deauthentication from 00:02:2d:65:0b:14 (reason=3)
wlan0 IEEE 802.11 ESSID:"AGSM"
Mode:Managed Frequency:2.462 GHz Access Point: 00:02:2D:65:0B:14
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Note the incorrect ESSID, with MAC/chan that match that (wrong) SSID.
iwlist wlan0 scan gives "No scan results"
doing "iwconfig wlan0 essid AGSM2" connects, and causes iwlist wlan0 scan to
start returning results and everything works without problems.
There is an ESSID 'AGSM', but its an older setup that I don't have config
details for - its not present in the NM config at all.
I'll attach scan results, but the 'AGSM' ESSID doesn't show up in those. I don't
know why - it used to (see attachment 299999 [details]). In the past I have noticed that
SSID showing up in the NM menu before the other APs, but its never bothered
Its possible that over the break some APs got decommissioned/broke, so that this
SSID is only barely in range/working/etc - I don't have any way of telling for sure.
Created attachment 308225 [details]
Created attachment 308294 [details]
With the AGSM essid
Caught the AGSM ESSID in scan results
Created attachment 308296 [details]
iwevent while this is happening
Here's iwevent while this is happening. I started running this at a VTY before
I logged in. Timestamps:
07:32:56 - log in via gdm
Immediately lots of 'new access point/cell' bits in the log, every 0.05 seconds
After a time, NM prompted for the key for AGSM2. I did cancel (7:34:24), and it
then moved on to try 'Uniwide' (a second configured ESSID - this one uses PEAP
for auth). After a while NM prompted for the username/pw details. I hit cancel
(7:34:58) and it stopped trying to connect. iwevent still showed
'Not-associated' entries at 1/0.05 sec or so.
I then did 'iwconfig wlan0 essid AGSM2' (07:35:18). Then I selected 'AGSM2'
from the nm-applet menu (7:35:50)
Created attachment 308297 [details]
This appears to be http://w1.fi/bugz/show_bug.cgi?id=261 which is fixed by http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff_plain;h=3e2ad1b932d827ddb038a5f9163bca766803811a
Looking at my attached logs, you can see the disconnect-while-associating stuff that seems to be triggering this.
wpa_supplicant rebuilt with that patch (which applies cleanly except for the changelog file) has been working fine for me.
Theres still a small issue where NetworkManager sometimes doesn't seem to be waiting long enough for wpa-supplicant's scan to finish and times out, but with this patch I can just click connect on the prompt when that happens and it works - previously I had to unload/reload ipw4965 and/or restart NM and/or reboot.
Thanks for finding that! I'll pull that patch into updates in the near future.
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:
F11 doesn't need this backported - its using the newer version