Bug 293701 - iwl3945 fails to associate to 802.11b AP
iwl3945 fails to associate to 802.11b AP
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-17 14:53 EDT by Derek Atkins
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.6.23.8-34.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-29 17:14:37 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 Derek Atkins 2007-09-17 14:53:38 EDT
Description of problem:

I'm visiting my parents who have an 802.11b (NOT b/g) AP.  They use WEP.  The
iwl3945 driver can authenticate just fine but fails to associate to the AP.  It
doesn't seem to matter whether I use Networkmanager or not, it fails either way.
 I see the following in my dmesg log:

eth1: Initial auth_alg=0
eth1: authenticate with AP 00:09:5b:cf:60:ec
eth1: RX authentication from 00:09:5b:cf:60:ec (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:09:5b:cf:60:ec
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:09:5b:cf:60:ec (capab=0x15 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: associate with AP 00:09:5b:cf:60:ec
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:09:5b:cf:60:ec (capab=0x15 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: associate with AP 00:09:5b:cf:60:ec
eth1: invalid aid value 0; bits 15:14 not set
eth1: RX AssocResp from 00:09:5b:cf:60:ec (capab=0x15 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: association with AP 00:09:5b:cf:60:ec timed out

Version-Release number of selected component (if applicable):

I tried this with both kernel-2.6.22.2-57.bz250913.1.fc7 and
kernel-2.6.22.5-76.fc7.  Currently running:

kernel-2.6.22.5-76.fc7
iwl3945-firmware-2.14.1.5-1
NetworkManager-0.6.5-7.fc7
wpa_supplicant-0.5.7-3.fc7

How reproducible:

This is 100% reproducible with my parents' Netgear MR814v2

Steps to Reproduce:
1. Attempt to associate to an 802.11b-only AP like the MR814v2
2. Watch it fail
3. Check dmesg
  
Actual results:

No association.  No network.  No IP Address.

Expected results:

It should associate and get an IP Address, even in 802.11b only mode.

Additional info:

Maybe http://bughost.org/bugzilla/show_bug.cgi?id=1394 is relevant?
Comment 1 John W. Linville 2007-09-17 16:36:17 EDT
Could be...Intel has been slow to propagate fixes for iwlwifi to upstream -- I 
just got a patch from them to update to 0.1.15.  The bug you referenced 
indicates this issue is fixed in 0.1.12 -- I'll let you know when I get an F7 
kernel that has this update so you can try it again.  Hopefully you visit the 
folks often enough to verify the fix when it gets there! :-)
Comment 2 Derek Atkins 2007-09-17 18:30:08 EDT
Well, F7's kernel still only has version 0.1.8kd of the iwl3945 driver, so... 
I'll gladly test a new kernel when you have one for me.  Maybe it can also
include the fix for bug #250913 too!  :-D

Thanks!
Comment 3 Trevor Campbell 2007-09-26 05:10:35 EDT
I get this as well when connected to Belkin F5D7231au4 access point ( but can
connect OK to Netgear WRG614V4)
Comment 4 John W. Linville 2007-09-28 10:08:40 EDT
Please try the kernels here:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=19787

They are very up-to-date w.r.t. the iwlwifi driver.  Does the issue persist 
for you?
Comment 5 Derek Atkins 2007-09-28 10:19:31 EDT
Unfortunately I wont be able to test this for two months, I'm afraid.  I'm about
1000 miles away from the MR814v2 router and wont be back there until
Thanksgiving.  But I'll gladly test it then if nobody else can get to it in that
timeframe.  Maybe Trevor from comment #3 can test it sooner?  Sorry for the
large delay.

I can only test bug #250913 here at home, and I can only test this bug when I'm
at my parents' place.

Thank you for your patience.  I'll leave this as NEEDINFO if that's okay (and if
I can?)
Comment 6 Derek Atkins 2007-10-09 12:04:01 EDT
FYI, I'm now running 2.6.22.9-91.fc7 but I wont be in a position to test this
for another five weeks.  I'll report on the status of this bug then.
Comment 7 Derek Atkins 2007-10-24 11:06:33 EDT
Not sure if this is related or not.  I was just at a friend's house and they
have a 2Wire access point which is an 802.11(b) only device.  When I try to
associate using 2.6.22.9-91.fc7 it fails and I see the following in my dmesg log:

eth1: Initial auth_alg=0
eth1: authenticate with AP 00:0d:72:c5:4d:81
eth1: RX authentication from 00:0d:72:c5:4d:81 (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:0d:72:c5:4d:81
eth1: associate with AP 00:0d:72:c5:4d:81
eth1: associate with AP 00:0d:72:c5:4d:81
eth1: association with AP 00:0d:72:c5:4d:81 timed out
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate
eth1: privacy configuration mismatch and mixed-cell disabled - disassociate

I'm not sure if this is the same issue or not; the "configuration mismatch"
message seems to be new.  Is this the same issue, or a new one?

(I'll be able to test this against the Netgear MR814v2 in a month).
Comment 8 Derek Atkins 2007-10-24 11:10:46 EDT
FYI, I'll have two more chances to test the 2Wire AP in the next month, once on
Nov 10th and then again around Nov 18th.  Then I'll get to test the Netgear on
Nov 21.
Comment 9 John W. Linville 2007-11-09 14:45:00 EST
Please try these kernels:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=23734

Do they work better for you?
Comment 10 Derek Atkins 2007-11-09 14:56:28 EST
I can test against the 2Wire this weekend; I wont be able to to test against the
MR814v2 until the 21st.  I was going to test 2.6.23.1-21.fc7 but I can test
2.6.23.1-49.fc8 as well.

I presume it will be okay to run the fc8 kernels on Fedora 7?
Comment 11 John W. Linville 2007-11-09 15:46:29 EST
Yes, I think that will work fine.
Comment 12 Derek Atkins 2007-11-10 22:34:24 EST
Okay, running 2.6.23.1-49.fc8 and I cannot connect to the 2WIRE AP.  When I try
I get the following in dmesg:

eth1: Initial auth_alg=0
eth1: authenticate with AP 00:0d:72:c5:4d:81
eth1: RX authentication from 00:0d:72:c5:4d:81 (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:0d:72:c5:4d:81
eth1: associate with AP 00:0d:72:c5:4d:81
eth1: associate with AP 00:0d:72:c5:4d:81
eth1: association with AP 00:0d:72:c5:4d:81 timed out

I'll still work on the MR814v2 in about two weeks.
Comment 13 Derek Atkins 2007-11-10 22:35:49 EST
Strangely, when I DO try to connect to the 2WIRE, it seems to reset the AP and
kick off everyone else.  Then when I stop trying to connect, it seems to come
back and everyone else gets back on the network.  So maybe this is a 2WIRE bug?
 Seems kinda fishy that Linux can cause the AP to crash, but stranger things
have happened.
Comment 14 Derek Atkins 2007-11-12 07:28:39 EST
Okay, another data point with 2.6.23.1-49.fc8 -- it failed to connect to my home
802.11a WEP-protected network.  It failed to associate.  I just downgraded back
to 2.6.23.1-21.fc7 and it's working again.
Comment 15 Derek Atkins 2007-11-21 21:16:29 EST
Okay, just tested with 2.6.23.1-21.fc7 and no, it did not work with the MR814v2.
 I get the following in dmesg when I try to connect:

eth1: Initial auth_alg=0
eth1: authenticate with AP 00:09:5b:cf:60:ec
eth1: RX authentication from 00:09:5b:cf:60:ec (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:09:5b:cf:60:ec
eth1: RX AssocResp from 00:09:5b:cf:60:ec (capab=0x15 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: associate with AP 00:09:5b:cf:60:ec
eth1: RX AssocResp from 00:09:5b:cf:60:ec (capab=0x15 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: associate with AP 00:09:5b:cf:60:ec
eth1: RX AssocResp from 00:09:5b:cf:60:ec (capab=0x15 status=18 aid=0)
eth1: AP denied association (code=18)
eth1: association with AP 00:09:5b:cf:60:ec timed out
Comment 16 Derek Atkins 2007-11-24 10:54:48 EST
For the record, I also tried with 2.6.23.1-49.fc8 and it also failed, so this
problem still exists there, too.
Comment 17 John W. Linville 2007-11-26 14:42:16 EST
AP denied association (code=18)

"Association denied because requesting STA does not support all of the data 
rates in the BSSBasicRateSet parameter."

Hmmm...
Comment 18 Derek Atkins 2007-11-26 15:00:56 EST
Well, technically it's true.  The requesting STA supports MORE data rates than
the AP, so it's not a 1:1 mapping.  :)

          Cell 02 - Address: 00:09:5B:CF:60:EC
                    ESSID:"[snip]"
                    Mode:Master
                    Channel:11
                    Frequency:2.462 GHz (Channel 11)
                    Quality=85/100  Signal level=-48 dBm  Noise level=-80 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                    Extra:tsf=000000c8e42d466d
Comment 19 John W. Linville 2007-11-27 11:35:46 EST
I think -62.fc8 will resolve the "code=18" issue.  I'm not sure when fc7 
kernels will have the fix.
Comment 20 Derek Atkins 2007-11-27 11:51:34 EST
I'm happy to test the fc8 kernel to verify the fix, if you think the kernel will
work with fc7.  If so... URL?
Comment 22 John W. Linville 2007-11-27 13:43:57 EST
This one is F7, I think it will work as well...

   http://koji.fedoraproject.org/koji/buildinfo?buildID=25270
Comment 23 Derek Atkins 2007-11-29 16:36:38 EST
W00t!  2.6.23.8-34.fc7 works!

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