Atheros-Based cards and MADwifi

802.11a is the choice for high-speed, high-density 802.11 networks, and most 802.11a devices on the market use Atheros chipsets.[*] The driver project is called the "Multiband Atheros Driver for WiFi," or MADwifi; the project's home page is http://sourceforge.net/projects/madwifi/.

[*] It is likely that any card with 802.11a support is based on an Atheros chipset. Rather than include a list that will quickly become outdated, I suggest you refer to the searchable list at http://customerproducts.atheros.com/customerproducts/.

Although best known for 802.11a support, there are several Atheros chips available. There are three generations of chipset. The initial chipset, the 5210, only supported 802.11a. It was followed by the first dual-band chipset, the 5211, which added 802.11b support. Most devices now on the market use the 5212, which is a dual-band/tri-mode chipset that can support 802.11a, 802.11b, and 802.11g. In addition to the different radio support, later generations are capable of performing much more complex security operations. All chipsets are supported by MADwifi.

Driver Architecture and the Hardware Access Layer (HAL)

MADwifi is split into two parts: an open source driver, and a closed-source library called the Hardware Access Layer (HAL). Atheros chipsets are extremely flexible, and capable of tuning outside the unlicensed bands because they use a limited form of a software-defined radio.

Atheros has interpreted FCC regulations as requiring that the HAL be kept closed. (Broadcom interprets the rules in the same way, and they have a similar chipset on the market.) FCC rules require that software-defined radios must not be modifiable by the user to operate outside of their certified frequency bands. Devices that do not enforce the terms of their certification are potentially subject to sanctions. If devices sold for use in the unlicensed spectrum were suddenly able to disrupt licensed communications, vendors of such devices might also be penalized.[*]

[*] Christian Sandvig, a professor at the University of Illinois at Urbana-Champaign, takes exception to the SDR interpretation of FCC rules in a paper titled "Hidden Interfaces to 'Ownerless' Networks" (http://www.spcomm.uiuc.edu/users/csandvig/research/Hidden_Interfaces.pdf).

For commercial products, ensuring that the software stays in the unlicensed spectrum is easyjust avoid compiling and distributing code that breaks the rules. Users cannot edit compiled code, so they are unable to break the rules. Open source software changes the game. Distributing code that follows the rules does not prevent modification that break the rules.

Atheros faced a choice: ship a driver with completely open source code and risk losing regulatory approval to sell chips, or find some way of protecting the radio spectrum. Obviously, a driver exists because they took the latter course. Rather than have the open source driver interface directly with the radio chipset, it accesses the radio through the HAL's API. The HAL is generic enough that it is used unchanged by many other operating systems developing open source drivers; there are zero dependencies on the host system software, though it does depend on the host hardware's instruction set. The HAL is available for x86 architectures (both 32- and 64-bit), ARM, MIPS, PowerPC, and XScale. Although closed-source code is often viewed with suspicion in the open source community, I consider it a sign of corporate commitment to the Linux platform that Atheros was willing to support the development of the driver.

Requirements

MADwifi makes extensive use of wireless extensions, and is consistently developed against the latest version. Either use a recent distribution with current wireless extensions support, or upgrade the kernel to a recent distribution.

Drivers often make use of other kernel functionality, and MADwifi is no different. Building MADwifi depends on having kernel headers and configuration files for the running kernel. If you have built a custom kernel for your hardware, by definition you have kernel source and configuration. Not all distributions will install the kernel source and configuration by default; you may have to find the right package.

UUCP tools will also be necessary to get the HAL. To safely transfer the binary HAL over arbitrary network paths, it is uuencoded. MADwifi's make script calls uudecode. Depending on your distribution, uudecode may be part of the shell archive utilities package (sharutils), or it may be part of a UUCP tools package.

Building the Driver

MADwifi is still under active development, and it changes regularly. Rather than having periodic packaged releases, it is constantly maintained in CVS. Fetch the latest version from CVS:

 root@bloodhound:~# cvs -z3 -d:pserver:[e-mail]:/cvsroot/madwifi co madwifi

When the command completes, the source code and (encoded HAL files) will be downloaded into a directory madwifi. To build the driver, use the standard open source command set:

 root@bloodhound:~# cd madwifi
 root@bloodhound:~/bloodhound# make
 (lots of build messages)
 root@bloodhound:~/bloodhound# make install

The main modules are wlan.o, ath_pci.o, and ath_hal.o. Several other cryptographic modules are loaded on demand to support particular encryption schemes. If the MADwifi build system cannot detect the right place in the filesystem to install to, you may need to manually place the required modules in the correct location and run depmod -a to update modules.

Using the Driver

Current versions of the MADwifi driver publish a list of supported cards to the kernel, which is revealed when module dependencies are built. The MADwifi driver supported device list includes several devices with the manufacturer ID of 0x168c, which belongs to Atheros. Provided that module dependencies are built correctly, there is no need to modify the PCMCIA configuration scripts.

Loading the driver creates an interface prefaced with ath. Most likely, it will be ath0, since you will only have one Atheros card running in your system. Older versions of MADwifi used the prefix wlan. If you see wlan0, update the driver.

MADwifi is correctly integrated with the Linux hotplug system. When the module is inserted, the hotplug system will attempt to register the interface. It is almost certain that the start-up scripts in place on your distribution will need to be edited. Open wireless networks can probably have light editing; using 802.1X requires heavier editing because the interface must be authenticated before starting DHCP.

Using Windows Drivers Under Linux

In addition to xsupplicant, there is one commercial program available from Meetinghouse Data Communications. Meetinghouse's AEGIS client supports a wide variety of EAP methods (MD5, TLS, TTLS, PEAP, and LEAP). Due to the difficulties in keeping up with new distributions, however, it is only officially supported on RedHat versions 8 and 9. The Linux version of the Meetinghouse supplicant does not support WPA for the same reason xsupplicant does not: the lack of a standard WPA keying API.

Not all card manufacturers have committed to supporting Linux. Revealing intellectual property by giving away driver source code is usually the major concern. Finding the engineering time to write, maintain, and support drivers given to the user community is another.

Drivers written natively for Linux are preferable for a variety of reasons. However, if your card vendor does not yet have a Linux driver, you can use the Windows driver through a wrapper program. Two software packages can run the Windows NDIS driver in a sandbox and translate Windows system calls into their Linux equivalents. The NDISWrapper project (http://ndiswrapper.sourceforge.net/) is a completely open source implementation. A company called Linuxant provides a commercial program called DriverLoader (http://www.linuxant.com/driverloader/) for the same purpose. Trial licenses are free, but ongoing use does require payment.