I've built a test kernel with bcm43xx wireless support, from http://bcm43xx.berlios.de/
It's a rawhide kernel but it installs and runs on FC4 with --nodeps
http://david.woodhou.se/kernel-2.6.14-1.1805_FC5.bcm43xx.ppc.rpm http://david.woodhou.se/kernel-devel-2.6.14-1.1805_FC5.bcm43xx.ppc.rpm
It seems to work, with WEP, if I set the ESSID manually -- but only for Legacy IP; not yet for IPv6 because there are multicast problems so it doesn't see the router advertisement. And suspend/resume is known not to work. But it's getting there, and it's already at the point where it might be useful to some people, and could certainly do with some more testing.
You need to fetch and use the 'fwcutter' tool to get the firmware into a form which the kernel driver will be able to use -- see the README at http://svn.berlios.de/wsvn/bcm43xx/trunk/fwcutter/README?op=file&rev=0&a... and download from ftp://ftp.berlios.de/pub/bcm43xx/snapshots/fwcutter/
Hi,
* David Woodhouse dwmw2@infradead.org [2005-12-31 07:30]:
I've built a test kernel with bcm43xx wireless support, from http://bcm43xx.berlios.de/
Thanks! I updated to rawhide today (yesterday I couldn't boot) and it appears the the device is visible.
It seems to work, with WEP, if I set the ESSID manually -- but only for Legacy IP [...]
I made it through the fwcutter stuff no problem but I'm a bit unsure as to where to go from here. At first I tried adding a device with s-c-n but that seems like it should be unnecessary. Do I need to do this to be able to use ifup? NetworkManager seems to be a bit broken for me ATM so I've been playing with iwconfig.
Immediately after boot, iwconfig shows the Airport Extreme device as eth0 but when I actually start up wired networking (with ifup eth0), iwconfig changes to list the device as "dev#####" where the #s seem to be the device number. Is this what I should expect? Is putting alias eth1 bcm43xx in /etc/modprobe.conf all I need to do?
Thanks. I'm very excited about this!
Andrew "networking newb" Overholt
On Wed, 2006-01-04 at 20:23 -0500, Andrew Overholt wrote:
I made it through the fwcutter stuff no problem but I'm a bit unsure as to where to go from here. At first I tried adding a device with s-c-n but that seems like it should be unnecessary. Do I need to do this to be able to use ifup? NetworkManager seems to be a bit broken for me ATM so I've been playing with iwconfig.
Hm. What's wrong with NetworkManager? It's working here.
Immediately after boot, iwconfig shows the Airport Extreme device as eth0 but when I actually start up wired networking (with ifup eth0), iwconfig changes to list the device as "dev#####" where the #s seem to be the device number. Is this what I should expect?
Possibly. I think this happens because it knows your wired Ethernet card by its MAC address and knows it should be 'eth0', but the bcm43xx driver is getting loaded first and hence getting the name 'eth0', so it has to be renamed out of the way. I'm surprised it's left with such a silly name though, rather than getting renamed to 'eth1'. I'd file a bug against whatever's doing the renaming... although I'm not entirely sure what that is. Hotplug, perhaps, or initscripts?
Is putting alias eth1 bcm43xx in /etc/modprobe.conf all I need to do?
You shouldn't even need to do that -- it should just get loaded automatically when we detect the appropriate PCI device.
If it has a silly name, fix that with 'ip link set <dev> name <name>':
ip link set devXXXXX name eth1
You'll need to make sure it's down (ip link set devXXXXX down) first, but it probably will be anyway. Or you could just unload the bcm43xx module and reload it, and hopefully it won't get renamed again.
Bring it up, set the WEP key if any, set the ESSID. Look in dmesg and you should see that it's associated. That is:
ip link set eth1 up iwconfig eth1 enc your-wep-key-here iwconfig eth1 essid your-essid-here dmesg
You should see something like this...
bcm43xx driver 0.0.1 bcm43xx: Chip ID 0x4306, rev 0x2 bcm43xx: Number of cores: 6 bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled bcm43xx: Ignoring additional 802.11 core. bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off bcm43xx: PHY connected bcm43xx: PHY disconnected bcm43xx: PHY connected bcm43xx: InitVals written bcm43xx: Radio turned on bcm43xx: Chip initialized bcm43xx: DMA initialized bcm43xx: 80211 cores initialized bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1447 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1447 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1447 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1447 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1447 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1447 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1447 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1447 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1449 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1449 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1449 bcm43xx: TODO: Incomplete code in keymac_write() at drivers/net/wireless/bcm43xx/bcm43xx_main.c:1449 bcm43xx: Keys cleared bcm43xx: set security called bcm43xx: .active_key = 0 bcm43xx: .level = 1 bcm43xx: .enabled = 1 bcm43xx: .encrypt = 1 SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:157:ieee80211softmac_assoc_work() SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:13:ieee80211softmac_auth_req() SoftMAC: Queueing Authentication Request to 00:06:25:4b:55:f8 SoftMAC: cannot associate without being authenticated, requested authentication SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:55:ieee80211softmac_auth_queue() SoftMAC: Sent Authentication Request to 00:06:25:4b:55:f8. SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:105:ieee80211softmac_auth_resp() SoftMAC: Open Authentication completed with 00:06:25:4b:55:f8 SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:157:ieee80211softmac_assoc_work() SoftMAC: net/ieee80211/softmac/ieee80211softmac_assoc.c:15:ieee80211softmac_assoc() SoftMAC: sent association request! SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:105:ieee80211softmac_auth_resp() SoftMAC: Authentication response received from 00:06:25:4b:55:f8 but no queue item exists. SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:105:ieee80211softmac_auth_resp() SoftMAC: Authentication response received from 00:06:25:4b:55:f8 but no queue item exists. SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:105:ieee80211softmac_auth_resp() SoftMAC: Authentication response received from 00:06:25:4b:55:f8 but no queue item exists. SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:105:ieee80211softmac_auth_resp() SoftMAC: Authentication response received from 00:06:25:4b:55:f8 but no queue item exists. SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:105:ieee80211softmac_auth_resp() SoftMAC: Authentication response received from 00:06:25:4b:55:f8 but no queue item exists. SoftMAC: net/ieee80211/softmac/ieee80211softmac_auth.c:105:ieee80211softmac_auth_resp() SoftMAC: Authentication response received from 00:06:25:4b:55:f8 but no queue item exists. SoftMAC: associated!
At this point, you should be associated with the AP, and you should be able to see network traffic. Assuming you run an IPv6 route advertisement dæmon (radvd) running, you should already have an IPv6 address on the card and it should be working. If you also need legacy IP, then also run 'dhclient eth1'.
On Thu, 2006-01-05 at 10:19 +0000, David Woodhouse wrote:
On Wed, 2006-01-04 at 20:23 -0500, Andrew Overholt wrote:
I made it through the fwcutter stuff no problem but I'm a bit unsure as to where to go from here. At first I tried adding a device with s-c-n but that seems like it should be unnecessary. Do I need to do this to be able to use ifup? NetworkManager seems to be a bit broken for me ATM so I've been playing with iwconfig.
Hm. What's wrong with NetworkManager? It's working here.
It seems to be working now. I have other problems now, though ...
ip link set eth1 up
This seems to have been the key. I can now see networks and such.
You should see something like this...
[...] SoftMAC: associated!
I see almost everything you say but it never associates with my access point. I've verified multiple times that the WEP key is correct but I always end up with (in /var/log/messages):
SoftMAC: cannot associate without being authenticated, requested authentication
and
SoftMAC: Authentication timed out with <access point MAC>
I guess I'll file a bug ... okay:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177060
Andrew
On Thu, 2006-01-05 at 21:29 +0000, David Woodhouse wrote:
On Thu, 2006-01-05 at 16:10 -0500, Andrew Overholt wrote:
SoftMAC: Authentication timed out with <access point MAC>
Hm. Try reducing the rate. 'iwconfig eth1 rate 11M'
Yay, that works!
Unfortunately, NM keeps resetting the rate to 54M and even trying to subvert it with iwconfig eth0 rate 11M calls during its operation, it keeps going back to 54M.
I guess there are still problems with suspend and this driver ;) ?
Thanks,
Andrew
On Thu, 2006-01-05 at 16:42 -0500, Andrew Overholt wrote:
Unfortunately, NM keeps resetting the rate to 54M and even trying to subvert it with iwconfig eth0 rate 11M calls during its operation, it keeps going back to 54M.
Hm, I didn't think NetworkManager set the rate. Is it taking the device down and bringing it back up again? Does it work if you don't use NetworkManager?
I guess there are still problems with suspend and this driver ;) ?
Suspend is working OK for me now.
On Thu, 2006-01-05 at 21:48 +0000, David Woodhouse wrote:
On Thu, 2006-01-05 at 16:42 -0500, Andrew Overholt wrote:
Unfortunately, NM keeps resetting the rate to 54M and even trying to subvert it with iwconfig eth0 rate 11M calls during its operation, it keeps going back to 54M.
Hm, I didn't think NetworkManager set the rate. Is it taking the device down and bringing it back up again? Does it work if you don't use NetworkManager?
I'm not sure how NetworkManager works exactly. I think it might actually be taking it down and bringing it back up again. I've CCd Dan Williams since he'll know what's happening here.
Yes, it works if I don't use NetworkManager.
I guess there are still problems with suspend and this driver ;) ?
Suspend is working OK for me now.
Oh, I stupidly only tried gnome-power-manager's Suspend. Closing the lid works great. Coming out of sleep, the driver is set back at 54M so I have to manually reset back to 11M.
Is this auto-rate switching issue something that needs to be further reverse-engineered or is it just something in the kernel driver (or something wonky in my case)?
Andrew
On Thu, 2006-01-05 at 17:04 -0500, Andrew Overholt wrote:
Oh, I stupidly only tried gnome-power-manager's Suspend. Closing the lid works great. Coming out of sleep, the driver is set back at 54M so I have to manually reset back to 11M.
Yeah, I think that's a known bug. Should get fixed shortly.
Is this auto-rate switching issue something that needs to be further reverse-engineered or is it just something in the kernel driver (or something wonky in my case)?
Doesn't even need reverse-engineering. We do it in software; we just need to implement that part of the low-level 802.11 stack (which is _also_ being developed alongside the bcm43xx hardware driver).
On Thu, 2006-01-05 at 17:04 -0500, Andrew Overholt wrote:
On Thu, 2006-01-05 at 21:48 +0000, David Woodhouse wrote:
On Thu, 2006-01-05 at 16:42 -0500, Andrew Overholt wrote:
Unfortunately, NM keeps resetting the rate to 54M and even trying to subvert it with iwconfig eth0 rate 11M calls during its operation, it keeps going back to 54M.
Hm, I didn't think NetworkManager set the rate. Is it taking the device down and bringing it back up again? Does it work if you don't use NetworkManager?
I'm not sure how NetworkManager works exactly. I think it might actually be taking it down and bringing it back up again. I've CCd Dan Williams since he'll know what's happening here.
Yes, it works if I don't use NetworkManager.
NM does try to set the bitrate to 0 in infrastructure mode. According to the WEXT spec, a bitrate of 0 means "default" or "unset", which means the card needs to clear any previously set bitrate and switch to its default bitrate. If you set a particular bitrate on the card, it is supposed to maintain that rate no matter what. Even if it would normally switch bitrates in response to changes in signal strength (which is normal), if the bitrate of > 0 is set, the card must keep that rate. Sending a 0 turns off the force-set bitrate.
Ad-Hoc mode is quite different, since most cards don't really work well in this mode (specifically, Atheros, orinoco, and possibly others) unless the bitrate is set explicitly. So NM attempts to set a bitrate of 11Mbps here by default. Broken, I know. Drivers should probably get fixed I guess.
NM also brings devices down and back up again in a few cases. This is usually in an attempt to clear settings from the card. If the driver/card has issues with a ~IFF_UP followed by an IFF_UP, then it needs to get fixed I'd assume...
What exactly are the issues that the driver has with NM?
Dan
On Thu, 2006-01-05 at 23:15 -0500, Dan Williams wrote:
NM does try to set the bitrate to 0 in infrastructure mode. According to the WEXT spec, a bitrate of 0 means "default" or "unset", which means the card needs to clear any previously set bitrate and switch to its default bitrate.
OK, then as soon as we fix the driver to automatically fall back to a working bitrate, rather than _staying_ at its default bitrate even though it can't associate with the AP, we should be fine with NM.
NM works OK for me with it anyway, since I can actually use 54M rate (although it's a lot better if I back down to 11M. I think we also have a txpower problem with higher rates).
What exactly are the issues that the driver has with NM?
I don't think any of them are NM's fault at this point. NM just pokes at it in a manner which is different to most of its testing, and undoes our workarounds like the 'rate 11M' trick.
One thing I did notice was that while the module lacked a module table entry for hotplug, NM complained of not knowing its driver name. Then it repeatedly triggered an assertion about a mutex being NULL. Remove the entries matching your card from /lib/modules/`uname -r`/modules.pcimap to reproduce.
I've now added the appropriate table to the bcm43xx driver -- but I'm not sure I should have done; I'm not entirely sure I _want_ it being autoloaded just yet. NM ought to have coped, surely?
On Fri, 2006-01-06 at 11:21 +0000, David Woodhouse wrote:
I've now added the appropriate table to the bcm43xx driver -- but I'm not sure I should have done; I'm not entirely sure I _want_ it being autoloaded just yet. NM ought to have coped, surely?
Part of the driver being a "good" driver is to populate its sysfs entries correctly. That means it needs both SET_NETDEV_DEV and SET_MODULE_OWNER. If there's no "driver" link in sysfs, I call the driver broken and it needs to get fixed. This isn't just for NM, it's also for HAL. NM just tries to get driver information from HAL, so its HAL that's not being able to find it.
Dan
On Fri, 2006-01-06 at 10:26 -0500, Dan Williams wrote:=
Part of the driver being a "good" driver is to populate its sysfs entries correctly. That means it needs both SET_NETDEV_DEV and SET_MODULE_OWNER.
It does both those things. It was the MODULE_DEVICE_TABLE() which made the difference -- or more to the point, it was the presence of an entry for the device in /lib/modules/`uname -r`/modules.pcimap. I thought that only affected autoloading, but it seems to affect HAL too.
On Fri, 2006-01-06 at 15:35 +0000, David Woodhouse wrote:
On Fri, 2006-01-06 at 10:26 -0500, Dan Williams wrote:=
Part of the driver being a "good" driver is to populate its sysfs entries correctly. That means it needs both SET_NETDEV_DEV and SET_MODULE_OWNER.
It does both those things. It was the MODULE_DEVICE_TABLE() which made the difference -- or more to the point, it was the presence of an entry for the device in /lib/modules/`uname -r`/modules.pcimap. I thought that only affected autoloading, but it seems to affect HAL too.
Is there a /sys/class/net/ethX/device/driver link both ways?
Dan
On Fri, 2006-01-06 at 11:07 -0500, Andrew Overholt wrote:
On Thu, 2006-01-05 at 23:15 -0500, Dan Williams wrote:
What exactly are the issues that the driver has with NM?
One issue that I'm not sure if known is that signal strength for all networks shows as 100%.
There could be two issues there:
1) NM needs to get updated for WE-19. The strength calculations were done pre-WE-19, and as such don't take some constants into account. I probably need to review the code here anyway.
2) HOWEVER: I'm blaming drivers first for strength. NM follows a quite strict interpretation of the rules for signal strength, as specified in the WEXT spec:
a) the driver can specify it's own qual->qual between 0 and max_qual->qual (from SIOCGIWRANGE) b) dBm: driver must specify max_qual->level = 0, and have valid values for qual->level and (qual->noise OR max_qual->noise) c) raw RSSI: driver must specify max_qual->level > 0, and have valid values for qual->level and max_qual->level
It turns out that as of today's SVN snapshot, the driver doesn't support SIOCGIWSTATS yet, so no signal quality for you. Furthermore, it doesn't hook up scanned signal quality to its internal network list, so ieee80211_wx_get_scan() can't get the quality data.
Dan
On Fri, 2006-01-06 at 11:30 -0500, Dan Williams wrote:
It turns out that as of today's SVN snapshot, the driver doesn't support SIOCGIWSTATS yet, so no signal quality for you. Furthermore, it doesn't hook up scanned signal quality to its internal network list, so ieee80211_wx_get_scan() can't get the quality data.
Yeah, we'll get there. For the time being, I'd assume that _all_ such problems are down to the bcm43xx driver, not to NetworkManager.
Today's bcm43xx snapshot should be in the 2.6.15-1.1829_FC5 kernel which is now building, btw.
On Fri, 2006-01-06 at 16:35 +0000, David Woodhouse wrote:
On Fri, 2006-01-06 at 11:30 -0500, Dan Williams wrote:
It turns out that as of today's SVN snapshot, the driver doesn't support SIOCGIWSTATS yet, so no signal quality for you. Furthermore, it doesn't hook up scanned signal quality to its internal network list, so ieee80211_wx_get_scan() can't get the quality data.
Yeah, we'll get there. For the time being, I'd assume that _all_ such problems are down to the bcm43xx driver, not to NetworkManager.
Today's bcm43xx snapshot should be in the 2.6.15-1.1829_FC5 kernel which is now building, btw.
Though quite soon we'll be tossing lots of the actual card/driver manipulation over to wpa_supplicant (even for unencrypted and WEP). So most of the bitrate, frequency, etc stuff won't be in NM anymore. Then we get to fix wpa_supplicant ;)
Dan
On Sat, 31 Dec 2005 12:29:14 +0000, you wrote:
I've built a test kernel with bcm43xx wireless support, from http://bcm43xx.berlios.de/
Using the latest rawhide kernel it is working fine for me using WEP and NetworkManager on a Dell laptop.
Only issue is it seems to be slower than ndiswrapper.
On Wed, 2006-01-04 at 22:05 -0500, Gerald Henriksen wrote:
Using the latest rawhide kernel it is working fine for me using WEP and NetworkManager on a Dell laptop.
Only issue is it seems to be slower than ndiswrapper.
Try manally slowing it down... 'iwconfig eth1 rate 11M' Try also 18M.
David Woodhouse wrote:
On Wed, 2006-01-04 at 22:05 -0500, Gerald Henriksen wrote:
Using the latest rawhide kernel it is working fine for me using WEP and NetworkManager on a Dell laptop.
Only issue is it seems to be slower than ndiswrapper.
Try manally slowing it down... 'iwconfig eth1 rate 11M' Try also 18M.
On my powerbook G4, 11Mbs works fine couldn't get 18Mbs to work. Also I have to statically set the IP address dhclient work work, it tries but finally dies. If I set the IP by and it works just fine.