Fedora Account System
Red Hat Associate
Red Hat Customer
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): 2.6.20-1.3054.fc7
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 > other. Correct. > 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 drivers). > 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 reasonable values.
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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.