March 22, 2019

Better Wi-Fi on the Linux Horizon - page 2

The Coming Alphabet of 802.11

  • April 26, 2007
  • By Carla Schroder

John 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.

Most Popular LinuxPlanet Stories