Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236294 - bcm43xx wireless can't associate w/AP when multiple APs in range have same WEP key
Summary: bcm43xx wireless can't associate w/AP when multiple APs in range have same WE...
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-12 21:26 UTC by Jarod Wilson
Modified: 2008-08-02 23:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-04 00:28:56 UTC

Attachments (Terms of Use)

Description Jarod Wilson 2007-04-12 21:26:27 UTC
Description of problem:
My PowerBook G4's bcm4306 wireless fails to associate with any access points
when there are multiple access points in range that have the same WEP key. For
instanace, I've never been able to get my laptop connected wirelessly in the
office under Linux (works in Mac OS X), and was able to reproduce this at home
with just two access points. When I pulled the plug on one of the two,
everything worked just fine.

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

Comment 1 John W. Linville 2007-04-13 17:26:12 UTC
Just to clarify, you have two APs with the same WEP key in range of each 
other.  Are they on the same channel?  Do they have the same SSID?

Have you tried with any other wireless hardware?  Do you get similar results?

Comment 2 Jarod Wilson 2007-04-13 20:47:31 UTC
(In reply to comment #1)
> Just to clarify, you have two APs with the same WEP key in range of each 
> other.


> Are they on the same channel?

No. I think I tried them both on the same channel and on different channels with
identical results, but I'd have to double-check that. Definitely on different
channels right now.

> Do they have the same SSID?

At home, no. In the office case, yes.

> Have you tried with any other wireless hardware?

On the AP side, I've mixed in an actiontec in place of one of my Linksys APs
with identical results. Not sure what the APs in the office are offhand, but I'm
guessing you do. :)

On the wireless card side, I've not tried anything else under Linux of late.
There's a wireless card in my mac mini and a desktop box I've got (both running
rawhide), but both are using wired connections at the moment. I'll see what I
can see with one of those, assuming they work at all... (mini has an atheros
card, desktop box has a ralink card, neither appears to have auto-loaded any

> Do you get similar results?

Will report back once I've been able to test...

Comment 3 Jarod Wilson 2007-04-13 21:06:10 UTC
I take it back, the ralink driver appears to be coming up all by itself. I'll
start with that one... :)

Comment 4 Jarod Wilson 2007-04-16 16:03:55 UTC
Okay, the ralink card works fine with both APs up and running, even when both
have the same WEP key and the same SSID (one set to channel 3, one set to auto).

Of course, so does the bcm43xx card. First time I've tried it at home with the
mac80211 stack bcm43xx driver and both APs up and running, so now to see if I
can reproduce with the older bcm43xx driver...

Comment 5 Jarod Wilson 2007-04-16 16:17:54 UTC
Figures. Old stack is working now too. I assumed things would behave the same as
they always had here at home following connection failures in the office late
last week. Oops. (Last time I had both APs on at home was under an FC6 kernel a
few months ago). I'll have to see what I can see in the office now, since I was
still unable to connect there late last week...

Comment 6 Jarod Wilson 2007-04-16 16:38:39 UTC
I take it back, I was just able to reproduce something that resembles the
problem using both bcm43xx drivers. Both APs have the same wep key, but are on
different channels and have slightly different names now, and I'm unable to
re-associate. I didn't get knocked off when I changed the name on the secondary
AP, but I was unable to associate with it, and then unable to re-associate with
the primary after I'd disconnected from it.

The situation is slightly better with the new stack, under which I at least
sometimes am able to establish a connection (2 out of 9 tries). Never did get
one in 10 tries with the old stack.

One other difference of note between the two bcm43xx drivers, but I presume
irrelevant to this issue: with the mac80211 stack, NetworkManager always reports
my connection strength as 100%, while the old stack seems to have much more
reasonable values.

Comment 7 Jarod Wilson 2007-04-17 15:45:45 UTC
Still fails to connect to an APs in the office, regardless of which driver I try. :(

Comment 9 John W. Linville 2007-05-18 18:32:09 UTC
Are you still experiencing this problem with current kernels?

Comment 10 Jarod Wilson 2007-05-18 18:39:14 UTC
Yes, kernel 3163 still has the same problem here in the office.

Comment 11 John W. Linville 2007-06-01 20:46:16 UTC
Honestly, the log suggests to me that this is a NetworkManager issue...

Comment 12 Bug Zapper 2008-04-04 00:03:33 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here: to ensure this
doesn't happen again.

Comment 13 Jarod Wilson 2008-04-04 00:28:56 UTC
Everything works just peachy with b43 now.

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