Bug 402981 - iwl3945: no SuppRates element in AssocResp
iwl3945: no SuppRates element in AssocResp
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-28 10:25 EST by Jon Stanley
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version: 2.6.23.9-85.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-14 20:14:08 EST
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 Jon Stanley 2007-11-28 10:25:46 EST
Relevant software:

NetworkManager-0.7.0-0.5.svn3030.fc8.x86_64
NetworkManager-0.7.0-0.5.svn3030.fc8.i386
kernel-2.6.23.1-49.fc8.x86_64
iwl3945-firmware-2.14.1.5-2.noarch

When attempting to associate with an open AP, received the following in dmesg:

wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:0f:cc:c4:64:10
wlan0: RX authentication from 00:0f:cc:c4:64:10 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:0f:cc:c4:64:10
wlan0: RX AssocResp from 00:0f:cc:c4:64:10 (capab=0x1 status=0 aid=35)
wlan0: no SuppRates element in AssocResp
wlan0: associate with AP 00:0f:cc:c4:64:10
wlan0: RX AssocResp from 00:0f:cc:c4:64:10 (capab=0x1 status=0 aid=35)
wlan0: no SuppRates element in AssocResp
wlan0: associate with AP 00:0f:cc:c4:64:10
wlan0: RX AssocResp from 00:0f:cc:c4:64:10 (capab=0x1 status=0 aid=35)
wlan0: no SuppRates element in AssocResp
wlan0: association with AP 00:0f:cc:c4:64:10 timed out
wlan0: RX deauthentication from 00:0f:cc:c4:64:10 (reason=2)
wlan0: deauthenticated

Here is the result from iwlist scan for the relevant AP:

wlan0     Scan completed :
          Cell 01 - Address: 00:0F:CC:C4:64:10
                    ESSID:"Think"
                    Mode:Master
                    Channel:6
                    Frequency:2.437 GHz (Channel 6)
                    Quality=68/100  Signal level=-65 dBm  Noise level=-92 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                    Extra:tsf=00000051f6e21163

Manual association with iwconfig appears to be somewhat successful, however
lacing a Bit Rate and link quality metrics as seen in the working example below,
and no DHCP address can be obtained:

wlan0     IEEE 802.11g  ESSID:"Think"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:0F:CC:C4:64:10   
          Tx-Power=17 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

This does not occur with all access points.  My access point at home works fine,
and it uses WPA2-PSK.  There are other open access points that are functional as
well:

wlan0     IEEE 802.11g  ESSID:"jstanley"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:18:39:85:08:D8   
          Bit Rate=54 Mb/s   Tx-Power=17 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Encryption key: <removed>
          Link Quality=93/100  Signal level=-37 dBm  Noise level=-67 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
Comment 1 Jon Stanley 2007-12-21 12:27:06 EST
Note that I've found from the access point MAC that it's a Netopia router -
which may be important.  I have not had this issue with any other type of AP,
nor do I have other Netopia hardware to try this with.  This is a public AP at a
coffee shop, so this can be reproduced whenever.  Next time I'm there I'll try
the then-latest kernel from koji and report back.
Comment 2 John W. Linville 2007-12-21 12:56:57 EST
Not sure how things are supposed to work if the AP does not advertise 
supported rates...I guess you could assume the required rates...hmmm...

Can you put your interface into monitor mode, then capture the association 
traffic using wireshark or tcpdump, and attach the capture here?  You'll need 
one wireless station for the monitoring and another for the association, but 
if it is in a public place that doesn't seem too difficult -- just a bit 
harder to capture the right traffic.

If that doesn't work for some reason (e.g. you are the only wireless customer 
at the shop), then I might be able to talk you through an alternative solution 
using a single wireless device -- let me know.

So, can you capture that information?
Comment 3 Jon Stanley 2007-12-21 13:46:26 EST
Not exactly sure how to do this.  I've got two laptops (one the personal laptop
running F8 and a work laptop that runs Windows).  They both use an iwl3945
actually, and the Windows machine works fine.  Other folks Linux machines (not
sure of what distro) seem to work as well.

Is there some way that I could use the Windows machine (w/Wireshark or whatever
else) to capture the required traffic?
Comment 4 John W. Linville 2008-01-07 14:26:30 EST
Yes, I believe wireshark works under windows.  If you could start wireshark 
capture before starting the linux wireless association, then stop it after 
ther failure, that would be helpful.  Please attach the output here...thanks!
Comment 5 Jon Stanley 2008-01-14 20:14:08 EST
Well, I can't reproduce this anymore - I noticed that when I opened this bug was
prior to the release of 2.6.23.9-85, and there were lots of wireless bits
changed between the last released update and this one.  I'm not sure what
changed in the iwl3945 driver, but my guess is that this was fixed upstream
somewhere.

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