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):
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?
(In reply to comment #1)
> Just to clarify, you have two APs with the same WEP key in range of each
> 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...
I take it back, the ralink driver appears to be coming up all by itself. I'll
start with that one... :)
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...
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...
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
Still fails to connect to an APs in the office, regardless of which driver I try. :(
Are you still experiencing this problem with current kernels?
Yes, kernel 3163 still has the same problem here in the office.
Honestly, the log suggests to me that this is a NetworkManager issue...
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Everything works just peachy with b43 now.