Better Wi-Fi on the Linux Horizon

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

Wireless networking on Linux is entering a new era. An era of bliss and ease; where users and network administrators have abundant time for relaxing lie-abouts on sunny warm hills because their wireless systems are humming along contentedly, instead of being vexing and unreliable.

OK, so maybe it’s not going to be quite that Utopian, but things are definitely looking up, thanks to a lot of hard work by a lot of talented developers.

So what’s going to be different? A brand-new wireless LAN (WLAN) kernel stack, which is going to reduce the current WLAN herd-of-cats approach to a single unified subsystem that supports all wireless drivers. It all started with Devicescape, which released its previously proprietary Advanced Datapath Driver under the GPL in May 2006, and which is now in the Andrew Morton (mm) kernel tree. Sometime not too long from now it will be merged into the mainline kernel. Devicescape says this delivers “the first-ever native Wi-Fi support in the Linux kernel.”

“What?” you cry, “Linux has had wireless support since forever!” Which is true, but as a hodge-podge of overlapping, disorganized drivers and utilities for different types of wireless devices. It hasn’t had a unified Wi-Fi-compliant subsystem until now.

A brief digression here, since this is a common point of confusion. Wi-Fi is a trademarked brand name with a specific meaning. It refers to drivers and devices that support the growing family of IEEE 802.11 wireless specifications. The current IEEE 802.11 wireless specifications that users and admins are most concerned with are:

802.11 legacy
802.11a
802.11b
802.11g
802.11i
802.11n

There are gobs more, all the way down the alphabet. So when you see 802.11n, for example, that is the name of the specification, even though it looks like a wildcard. 802.11x is the unofficial wildcard that means “all official 802.11 guff.” What happens when they get to the end of the alphabet? They’re already there–802.11x is reserved and will not be used, to avoid confusion with the 802.1x standard for port-based access control. I know, I know, don’t blame me, I’m just the messenger.

There are a number of wireless extensions outside any 802.11 specification. A common one is the “turbo-boost” or “speed booster” features you see advertised on a lot of wireless devices. Each vendor has its own way of implementing these. Some use channel-bonding, some use packet- or frame-bursting. There is also disarray over 802.11n, which defines MIMO (multiple input, multiple output antennas), which is also hyped as generating more speed. Mostly these are incompatible with each other and cause various problems, which is why you read “buy all of your gear from the same vendor.” A pox on that, I say! Freedom for the people! That’s why we have industry standards.

The good news is eventually it will all sort itself out, because after all this is all new bleeding-edge fun.

OK, so maybe it’s not going to be quite that Utopian, but things are definitely looking up, thanks to a lot of hard work by a lot of talented developers.

802.11 legacy
802.11a
802.11b
802.11g
802.11i
802.11n

The good news is eventually it will all sort itself out, because after all this is all new bleeding-edge fun.

OK, so maybe it’s not going to be quite that Utopian, but things are definitely looking up, thanks to a lot of hard work by a lot of talented developers.

802.11 legacy
802.11a
802.11b
802.11g
802.11i
802.11n

The good news is eventually it will all sort itself out, because after all this is all new bleeding-edge fun.

ohn Linville, ace kernel developer and kindly answerer-of-questions, shared a lot of interesting information about the shiny new Linux wireless code.

Currently the goal is to replace the elderly (but all lifesavers in their time) wireless-tools extensions, the ieee80211+softmac layer, and perhaps someday the ieee80211 subsystem. Mr. Linville explains some of the challenges in supporting modern wireless hardware:

“Early wireless networking hardware went to a lot of trouble to look like ethernet adapters. This generally involved an on-board controller running firmware that accepted ethernet frames from the host, converted them to wireless frames for transmission, and then did the reverse on reception. These are referenced as “full MAC” devices, because they implement this MAC-layer functionality on the hardware itself. Of course, having a controller and memory for the firmware adds cost to the hardware. So, most newer (especially consumer-grade) hardware has minimized or eliminated those components. This leaves some or all of the explicitly wireless networking bits in the hands of the host CPU. (Such devices are referenced as “half MAC” or “soft MAC” devices, because they rely on software to implement this MAC-layer functionality.)”

Currently the ieee80211+softmac layer does this job for a number of devices. A notable exception is Atheros-based interfaces, which are supported by the MadWiFi drivers. As Mr. Linville said

“Some drivers (notably MadWifi and many drivers for “other” operating systems) simply implement the wireless bits themselves, while still presenting themselves to the host networking stack more-or-less as ethernet devices. The problem here is that each driver is then responsible for re-implementing this functionality. This is not only wasteful of programming talent, it is also error prone and likely to result in inconsistent behaviour and feature support between different drivers.”

Which explains a lot of the problems with trying to build a Linux-based wireless access point. I use Atheros-based interfaces because they deliver all the functionality that I want: AP (Access Point) Mode, Managed, Ad-Hoc, Monitor, and WDS (Wireless Distribution System), which supports wireless mesh networks. But Atheros has the infamous binary kernel blob problem. Other wireless interfaces just don’t do what I want. But there is hope for more choices:

“One example of this is that AP mode is only supported by a handful of hardware in today’s mainline kernels, while potentially it could be supported by many more devices if the driver authors did not have to do all the work themselves. By providing the mac80211 component, the Linux wireless community can provide a consistent feature set across a broad range of wireless drivers while minimizing the effort to create and maintain those drivers. Surely that sounds impressive!”

You’re darn tootin’ it does. Which leads us to the main components of the new WLAN subsystem:

• mac80211: Common driver base for soft-MAC devices
• cfg80211: Kernel wireless API (Application Programming Interface)
• nl80211: User-space API

The existing ieee80211 system is going to be needed for awhile yet. It supports the older ipw2100 and ipw2200 drivers (for Intel Pro interfaces), which are full MAC devices. The current plan is to refactor some of the code from ieee80211 and mac80211 and use that to build a nice new lib80211. Then the remaining bits of ieee80211 will be converted into a library specifically to support the ipw2100 and ipw2200 drivers, which will be called libipw or something equally hummable.