bcm43xx and the 802.11 stack

The Broadcom 43xx family is yet another wireless network chipset without free driver support. There is, however, a proprietary Linux driver available; for example, the LinkSys WRT54G router has a Broadcom module. A reverse engineering team has been busily looking at that driver with the idea of writing a document describing how this chipset works; the resulting free bcm43xx specification is in a reasonably complete state.

Independently, the bcm43xx driver team has been writing a driver from this specification. The authors have never worked with the original, proprietary driver, so they should be unable to infringe any copyrights which cover that driver. This project has been moving along quietly for a while, but the quiet period is over: the free bcm43xx driver is now working. It is not for the faint of heart at this point, but it is able to transmit and receive packets. Adventurous souls with suitable hardware are encouraged to start testing the new driver.

While almost everybody is happy to see a free driver for this hardware, there have been some complaints about it. In particular, some developers are unhappy about the "softmac" layer used by the bcm43xx driver. This layer handles many media access tasks - scanning, management frames, etc. - for the driver. This functionality is not currently a part of the Linux 802.11 stack because the chipset for which that stack was initially developed - Intel's ipw chips - performs those tasks in hardware. Most other chipsets rely on the host for this functionality, so some sort of "software MAC" must be provided.

The problem is not that there is no softmac implementation for Linux; instead, there are too many of them. The softmac layer used by the bcm43xx driver, which is meant to integrate with the current kernel 802.11 stack, is one. The MadWifi project includes its own 802.11 stack, including a software MAC implementation. There is also a complete 802.11 stack from Devicescape available. Both the MadWifi and Devicescape stacks are said - by their supporters - to be more capable than the in-kernel stack, with or without the softmac layer. So why, they ask, should yet another software MAC be written using the in-tree 802.11 stack when better alternatives exist?

Your editor will not attempt to draw any conclusions about which implementation is the best. The simple fact, however, is that the in-tree 802.11 code is what developers have to work with now. Efforts to work with and improve that code will be better received by the networking maintainers than pointing at out-of-tree parallel implementations. So the softmac code used by the bcm53xx driver would appear to have an advantage going forward: it builds on the existing, in-tree code, and makes new capabilities available for all drivers.

Meanwhile, those who are interested in playing with the bcm43xx driver may want to avail themselves of the daily snapshots posted by the project.

---

(Log in to post comments)