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
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
to post comments)