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) kernel-2.6.25.4-39.fc9.x86_64 NetworkManager-0.7.0-0.9.3.svn3623.fc9.x86_64 wpa_supplicant-0.6.3-5.fc9.x86_64 How reproducible: Most of the time, but not always Steps to Reproduce: 1. Boot/resume laptop 2. NM should try to connect to ssid 'AGSM2' Actual results: 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) iwconfig shows: wlan0 IEEE 802.11 ESSID:"AGSM" Mode:Managed Frequency:2.462 GHz Access Point: 00:02:2D:65:0B:14 Tx-Power=14 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off 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" Expected results: connects. Additional info: 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 anything before. 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] iwlist scan
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 or so. 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] relevent /var/log/messages
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
F11 doesn't need this backported - its using the newer version