On Sun, 2008-07-27 at 05:59 +0000, Greg Matheson wrote: > I seem to be only able to get a bcm4306 chip to work when I power > on, but powering on does not seem to be a sufficient condition > for it to work. I am wondering if powering on after some time off > is necessary and sufficient?
You mean it doesn't work after reboot? > This is with 2.6.25-14.fc9.i686 or 2.6.25.10-86.fc9.i686. > > And I can only get this result with 4.150.10.5 firmware. > With 3.130.20.0 firmware, ie b43legacy. after associating with > the AP, it disassociates with reason=3. That is, it > disassociates of its own accord. > > That is, I haven't been able to get it working with 3.130.20.0. You should not be able to use b43 and b43legacy with the same device. Perhaps you patched one of those drivers to support your card? Then please be specific. > I wasn't able to get 4.80.53.0 working either, though I haven't > tried as much. > > Actually, I think b43legacy is the track this chip should be > working with, rather than b43, because I think it has a 'MAC core > revision' of 2, ie less than 4. > > b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, > Revision 2 What matters is the 802.11 core revision reported by the ssb driver when SSB debugging is enabled. b43 doesn't report it. Perhaps ssb is too quiet without debugging. > b43-phy0: Broadcom 4306 WLAN found > b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2 > b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 I have a bcm4306 card with the same PHY and radio, and it's supported by b43 only. b43legacy can be patched to support it. I have no problems with that card, even with reboots. > The output of uname -a: > > Linux pl757.nas921.nara.nttpc.ne.jp 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul 7 > 20:46:03 EDT 2008 i686 i686 i386 GNU/Linux Fedora is known to pull some experimental stuff into its kernels. Anyway, it's not the latest Fedora kernel, please upgrade if you can. And all real wireless work is done on the wireless-testing kernel. > [EMAIL PROTECTED] ~]# dhclient wlan0 -v > Internet Systems Consortium DHCP Client 4.0.0 > Copyright 2004-2007 Internet Systems Consortium. > All rights reserved. > For info, please visit http://www.isc.org/sw/dhcp/ > > Listening on LPF/wlan0/00:07:40:c4:f5:d6 > Sending on LPF/wlan0/00:07:40:c4:f5:d6 > Sending on Socket/fallback > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. dhclient on Fedora brings the interface down briefly. b43 is very susceptible to disassociation if it happens (but sometimes the connection survives). A workaround it to avoid dhclient. If you have to use it, you'll need to set essid in another session while dhclient is waiting, or run "wpa_cli -i wlan0 reassociate" It is a known problem, but I think dhclient is entirely to blame. Bringing the interface down goes well beyond the "zone of responsibility" of dhclient, as it affects the lower layers that need to stay connected and keep their state. -- Regards, Pavel Roskin _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
