Bug 449754

Summary: Doesn't connect to AP - incorrect ESSID being used?
Product: [Fedora] Fedora Reporter: Bradley <bbaetz>
Component: wpa_supplicantAssignee: Dan Williams <dcbw>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: dcbw, wtogami
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-10 06:16: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
iwlist scan
none
With the AGSM essid
none
iwevent while this is happening
none
relevent /var/log/messages none

Description Bradley 2008-06-03 12:41:58 UTC
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.

Comment 1 Bradley 2008-06-03 12:41:58 UTC
Created attachment 308225 [details]
iwlist scan

Comment 2 Bradley 2008-06-03 21:41:22 UTC
Created attachment 308294 [details]
With the AGSM essid

Caught the AGSM ESSID in scan results

Comment 3 Bradley 2008-06-03 21:51:59 UTC
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)

Comment 4 Bradley 2008-06-03 21:55:09 UTC
Created attachment 308297 [details]
relevent /var/log/messages

Comment 5 Bradley 2008-08-08 04:54:46 UTC
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.

Comment 6 Dan Williams 2008-08-08 14:35:15 UTC
Thanks for finding that!  I'll pull that patch into updates in the near future.

Comment 7 Bug Zapper 2009-06-10 01:22:25 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 8 Bradley 2009-06-10 06:16:14 UTC
F11 doesn't need this backported - its using the newer version