OLS: The state of Linux wireless networking

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

Kernel wireless maintainer John Linville outlined the past, present, and future of the Linux wireless stack on the first day of this year's Ottawa Linux Symposium. In his presentation, he ranged from early efforts, which were "a sore spot for Linux" to the future where it is likely that Linux will have support for some features before "that other OS". Along the way, he looked at various issues that wireless support in Linux faces, including vendor participation, suspend and resume, and regulatory issues.

Linville has been the maintainer Linux wireless for two and a half years since being recruited into the job by David Miller and Jeff Garzik. When he took over, wireless support was in disarray, as there were competing stacks to support different hardware. Users were faced with lots of pain in getting things working when "they just want their hardware to work" said Linville. Since that time, things have greatly changed.

The original wireless hardware was what is called "Full MAC hardware", where the implementation of the wireless protocols was handled by the hardware, generally in firmware. The drivers made these devices appear to be regular wired ethernet devices, though they did require some special configuration for SSID and the like. Because the hardware would enforce various regulatory requirements, vendors would generally work with the community in order to support the hardware.

All of that changed with the advent of "Soft MAC hardware"—which Linville likened to winmodems—where the CPU implements most of the protocol. It is a cheaper solution for vendors, but it requires an 802.11 stack for the kernel. The ieee80211 drivers came along to support the Intel Centrino wireless hardware, but they only supported those few devices. Johannes Berg added the ieee80211softmac driver that added some additional hardware support, but it was a kludgy solution. Since then, Linville said, folks have realized that it was "sort of a mistake to go down that road".

Enter the Devicescape stack. It was a feature rich 802.11 stack for Linux that was popular with developers. After some locking and SMP problems were resolved, it was merged into 2.6.22 as the mac80211 driver. Once that happened, wireless drivers started using it, to the point where Linville showed a chart of the current drivers, almost all of which use mac80211 . "It's been a boon to us to pick up the mac80211 code."

One notable driver that does not support mac80211 is the libertas driver for the OLPC. Unlike most other current devices, it is a Full MAC device with special requirements. It has support for power saving modes that do not yet exist in mac80211 . Because it is a mesh-networking device that still participates in forwarding network traffic when the system is powered down, it has needs that are not yet supported.

Drivers in progress was the next topic Linville addressed. Several of these are in need of developers to work on them, specifically for the Airgo chipset and Atmel USB chipset. The TI chipset drivers have had some questions raised about the reverse engineering process and may require a legal vetting similar to what the SFLC did for ath5k. Marvell is sponsoring development of a mac80211 based driver for its hardware. This driver may also support 802.11n which allows for greater range and higher speeds than current-generation 802.11.

Using data from LWN, Linville looked at the activity level of the wireless development in Linux. He was amazed to note "how much of the 2.6.26 kernel came through this laptop". Using his Signed-off-by as a proxy for wireless LAN commits, he noted 4.3-5.6% of the kernel commits in the last three releases (.24 through .26) were for wireless. In each kernel, wireless was either the fourth or fifth highest number of commits.

The compat-wireless-2.6 project is aimed at supporting newer hardware in older kernels. Because folks are wary of running kernel.org kernels or their distribution supports an older kernel—but they want to run with the latest hardware—the project backports wireless drivers to kernels as old as 2.6.21. It is a set of scripts and patches that build against the user's kernel. Unfortunately, the project may not last much longer as the multiqueue changes that have been merged for 2.6.27 may change the drivers enough that they will be infeasible to backport.

At the top of the list for new features is removal of the wireless extensions in favor of the new cfg80211 mechanism. According to Linville, "nobody likes wireless extensions, and nobody likes the existing tools". The wireless extensions have vague semantics, can have problems with race conditions, and because they are implemented by ioctl() calls, they encourage duplication of code in multiple drivers. cfg80211 will bring a much cleaner API along with fixing some existing bugs like the 31 character limit for SSIDs.

Access point (AP) mode is another feature that is coming. Typically, APs use similar or identical hardware to that in wireless MACs. For Soft MAC hardware, all that is needed is support on the CPU side for AP mode, which is coming for mac80211 . Mesh networking, which has been popularized by the OLPC project, is also coming to mac80211 . Cozybit has provided an implementation which will allow Linux to have a feature unavailable for Windows.

Areas that are needed, but are not yet being worked on was next on Linville's agenda. Suspend and resume support is "flawed for mac80211 due to connection management issues". Because mac80211 is unaware of suspend and resume, drivers must work around it by de-registering and re-registering with it, which can be slow. Adding support for suspend and resume is on the list, as is supporting power saving modes.

Linville went on to discuss three big issues that are largely outside of the control of the wireless hackers: firmware licensing, vendor participation, and regulatory concerns. Because drivers for Windows come with the firmware in the driver, many hardware vendors do not license the firmware blob separately. This means that it is unclear what can be done with those blobs. Certain vendors—Intel and Ralink were specifically called out—provide liberal licenses for their firmware. Users are encouraged to "vote with your dollars" by purchasing devices that either do not require firmware or that have a clear, free software friendly license.

Another consideration when deciding which vendors to support is whether they are engaged with the community. For the most part, all vendors but Broadcom are working with the wireless hackers by providing documentation and/or source code. Some are even providing dedicated developers to work on Linux drivers—Intel was the first, but both Atheros (which just released a driver for its ath9k hardware) and Marvell have also begun doing that.

Government regulations about what can and cannot be done in the unlicensed frequencies used by wireless are a concern that is frequently cited by vendors when refusing to work with the community. Unfortunately, their concerns are not completely without merit as hardware vendors are expected to ensure compliance with the regulations. "Non-compliance could be a huge loss" for those companies. As Linville points out, though, most vendors find a way to support Linux drivers.

In answer to a question, Linville said that most WiMAX and 3G wireless devices are Full MAC designs, so there should be little or no regulatory concern, which, in turn, means that Linux support should not be much of a problem—at least until Soft MAC devices come along. Overall, Linux wireless has come a long way, but there is lots still to do. One gets the sense that the wireless team is up to the task.