The 2006 Wireless Networking Summit

Group photo: 1000x620, 2200x1360

Your editor was fortunate enough to be able to attend this meeting. The following report is an attempt to summarize the conclusions from the summit - it is not a set of detailed minutes, and your editor will engage in some chronological reordering along the way. Hopefully the result will provide a sense for where things stand, and where they are likely to go in the near future.

History

As John Linville (the recently-named wireless networking maintainer) noted in a conversation with your editor, early wireless adapters were marketed as "wireless Ethernet," and Linux kernel developers treated them as a sort of slow, unreliable, fiddly Ethernet adapters. But wireless is not Ethernet in any way - it is a completely different set of networking standards with its own quirks, special features, and distinct needs. Treating wireless as a form of Ethernet slowed support for those special features, and, more importantly, impeded the development of any sort of internal kernel support for wireless. Each developer who set out to write a driver for a wireless adapter ended up implementing everything from the beginning. So there was no general wireless API, no comprehensive support of wireless features, and a great deal of divergence and duplication of code between drivers.

In 1997, Jean Tourrilhes decided to do something about this situation. The result was WE-1 - the first version of the Linux wireless extensions. There was still no 802.11 standard at the time, but the WE API enabled the configuration and operation of wireless adapters with a single set of tools. Jean's wireless tools are still the core utilities for managing wireless adapters, though the graphical interfaces are replacing the wireless tools for most users.

Development of the wireless extensions continued, with WE-9 - supporting the new 802.11 standard - being released in 1999. WE-18, merged last year, added support for WPA ("WiFi Protected Access"). The current revision, WE-20, adds a new, netlink-based interface as a future replacement for the current ioctl() API.

Though development continues, there appears to be a general, shared feeling that the wireless extensions are heading toward the end of their useful life. A replacement API - which does not exist yet - would work with the entire wireless networking stack, rather than being an interface directly to the low-level drivers. Regardless of how that plays out, however, the wireless extensions are likely to be around for a long time to come.

The current status

The current effort to create a proper wireless stack for Linux started in 2004, when Jeff Garzik announced the creation of a special wireless tree, initially seeded with the HostAP code. The merging of HostAP enabled support of some relatively current networking cards and the use of a Linux system as a wireless access point. The creation of this tree did help to get things going, but HostAP has not turned out to be everything that had been hoped for. In particular, there is no support in HostAP for cards which need software MAC ("softmac") implementations. But many contemporary cards rely upon the host software for many low-level operations; these cards can not be supported by the wireless stack found in the current (2.6.16) kernel.

The result is, as John Linville put it, a Linux wireless implementation which supports "anything which is obsolete." Some cards are supported, some better than others. Most noteworthy among current hardware is the set of Intel IPW drivers, which, thanks to Intel, have very good support in the kernel - but these adapters do not need softmac support.

What is lacking, at this point, is a small list of mildly desirable features, including support for much widely-used hardware. Ease of use is also lacking - despite improvements in the graphical tools, configuring a wireless connection can still be a painful procedure. Perhaps the best demonstration of these two problems was to be found at the summit itself, where about 25% of the participants ended up using an Ethernet cable to plug directly into the OSDL network.

Other problems include consistency (or the lack thereof) across hardware - there are still a number of adapter-specific APIs in the kernel and in the out-of-tree drivers. The documentation of APIs is, well, nonexistent; a complaint was heard that Linux Device Drivers does not describe how to write a wireless driver. There is no coordinated process for extending APIs. Quality of service support is not present - an issue we'll return to shortly. There are no driver test suites in general circulation. And the whole regulatory issue looms over the wireless networking arena, and is the largest single cause of out-of-tree (or nonexistent) wireless drivers. Many vendors simply do not feel that they can release programming information or free drivers and remain compliant with regulatory regimes worldwide.

Meanwhile, the upcoming 2.6.17 kernel will see some improvements in its wireless support. John merged one of the many softmac implementations out there, on the theory that it was one of the most active projects and that it would help to support driver development. The bcm43xx (Broadcom) driver, which uses softmac, was also merged, and there are a couple of other softmac-based drivers under development. Even so, the consensus appears to be that softmac is not the way forward; that, instead, the Devicescape stack is the real future of Linux wireless.

Devicescape

Devicescape is a company which offers a number of products and services around wireless networking. In developing it offerings, Devicescape created its own, Linux-based 802.11 stack with a number of nice features - including good softmac and WPA support . This stack was recently released under the GPL and has been fixed up for the kernel by Jiri Benc. It is regarded by many as being the best of the available free stacks.

When Jeff Garzik maintained the wireless tree, he took a firm position against moving to the Devicescape stack, stating instead that the in-kernel code should be evolved toward the needed capabilities. He appears to have found himself in the minority, however, and John Linville seems poised to merge this stack for a future kernel release. He maintains a separate development tree which includes Devicescape, and some drivers (notably bcm43xx) have been ported to this stack. Nobody at the summit was heard to argue against merging Devicescape.

Devicescape hacker Simon Barber talked about this code for a bit, and a separate breakout session addressed it as well. This stack is a large body of code. The freely-released code available now includes the 802.11 stack, the "openap" access point code, and a link-layer bridging module. Work which will be released soon includes improvements to the hostapd daemon (802.11g support, among other things; this code is being merged now); bridging and VLAN integration, and various improvements to Ethereal for wireless developers. There is also "a complete home gateway distribution" in the works. There is the inevitable web portal being put together to provide access to all this code.

Quite a bit of work is foreseen for the Devicescape stack. It is composed, internally, of a long list of handler functions which deal with frames (both data packets and 802.11 management frames) on their way to and from the adapter. Future plans call for enabling loadable modules to plug in their own handler functions. More of the management code may also eventually be moved out to user space. To that end, some additional management capabilities will be added to the hostapd daemon, which handles authentication and management tasks. Merging hostapd with wpa_supplicant, which handles the client side of the authentication process, is envisioned; evidently a number of things become easier when the two functions are merged into the same process.

There is also a great deal of complexity coming with the long list of future 802.11 standards. These standards will require support as they are adopted.

One interesting area of development has to do with quality of service support. 802.11 defines four service levels: "voice," "video," "best effort," and "background." There is a priority range for each service level, and the ranges overlap. All voice packets will go out before any background packets, but the rest of the levels will share the available bandwidth. With proper QoS support, a wireless user can carry on a voice-over-IP conversation, stream video of the latest "breaking news" celebrity sighting from CNN, grab a new kernel by FTP, and distribute materials (best not to ask what) via Bittorrent. Each activity can operate at its own quality of service level, and all should get the best available performance.

Some wireless network adapters have quality of service support in the form of four separate transmit queues. If the host places each packet in the appropriate queue, the adapter will divide the available bandwidth between them in a way which respects each level's service quality. The problem is that the Linux networking stack only supports one transmit queue per device. This presents a problem when one of the four device-level queues fills up. There is no way to tell the kernel that no more background packets can be queued, but there is still space for voice packets, for example; the only thing the driver can do is to stop the queue for all packets.

The Devicescape hackers have worked around this problem using the traffic control mechanism built into the networking stack, which normally operates at a level not seen by driver code. By creating a separate internal queue for each service level, the Devicescape stack can, for all practical purposes, implement a separate transmit queue for each service level. Even better, it becomes possible to configure policy - which types of traffic get which service level - from user space using the normal traffic control tools. What would be nice, however, would be to generalize this use of the queueing discipline code, and to make it available for other sorts of hardware as well.

Another area requiring work is user-space API definition. There is no well-understood API which, for example, can be used by a graphical wireless management utility to talk with the networking stack and with processes like hostapd. There isn't really even a discussion of how such an API should look at the moment.

Other open issues include the usual regulatory hassles, the lack of a user-space MAC-layer management environment, the need for better scanning, support for adapters which perform MAC management in hardware, power management support, and a rework of the configuration interface. Configuration is handled by way of ioctl() calls and a /proc interface. It was noted, in a pointed manner, that the Devicescape code will not make it into the mainline as long as it contains /proc files. It seems that the Devicescape stack also needs some work before it will operate properly on SMP systems.

Finally, adding proper wireless support to the kernel will involve the creation of a specific net_device type for 802.11 devices. An 802.11-specific sk_buff structure should also be defined. Current code still uses the Ethernet types and drags along the extra needed information on the side.

The biggest open issue, however, may be this: what happens to the just-merged softmac code when Devicescape is merged? There is much duplication of functionality there, and nobody is thrilled by the idea of having to maintain two separate 802.11 stacks indefinitely into the future. There is a clear parallel with the OSS and ALSA sound drivers; ALSA was supposed to replace OSS, but removing the OSS drivers has proved to be a difficult thing to do. It is not clear what can be done to make removing softmac any easier.

Tools

The summit was mostly attended by kernel-oriented developers, but there was also some discussion of user-space tools; NetworkManager hacker Daniel Williams was present. It is recognized by all that, while the quality of the available tools has improved significantly in the last couple of years, there is some ground to cover yet. In particular, configuring an interface can be relatively painless when things go well, but, as soon as something doesn't quite work, the whole experience falls apart.

Improving the situation will require support from the kernel side. When things go wrong, user space needs to know just what the problem is. But there is no consistent set of error codes returned by the kernel to indicate, for example, that the required adapter firmware is not present, or the provided WEP key is not valid. Some drivers support more of the current API than others, which does not help, and API documentation is generally not available. Better scanning support would also be useful.

Hardware support

While getting the networking stack and user-space tools into shape is necessary, improving hardware support is also a necessary step toward a Linux wireless implementation which truly "just works." Some hardware (Intel, others) is well supported now, others (Broadcom) will be supported soon. Some, such as the Atheros chipset, may be a long time in coming. The existing Atheros driver (as found in OpenBSD) appears to be severely tainted by code of questionable origin, to the point that its chances of being merged into Linux are about zero. There is an effort to document the Atheros hardware from the currently-available code, enabling a clean-room driver implementation in the future, but there is quite a bit of work yet to be done.

The regulatory compliance issue came up again in this context. Some adapters (such as Atheros) are, for all practical purposes, general-purpose radios which can be programmed to operate far out of the 802.11 specification. When a free driver is developed for such hardware, it would be a Good Thing to be sure that it runs the hardware in a manner compliant with the applicable regulations, even if it cannot necessarily be certified as such. That sort of testing requires specialized equipment, however, and is evidently a multi-day process. The necessary equipment does exist at companies like Nokia and at some universities, but there is currently no process for obtaining access to that equipment for compliance testing.

Much of the current driver work is done outside of the mainline tree, and the kernel developers would like to see that changed. Once code gets into the mainline, it is easier for others to review and improve. Greg Kroah-Hartman encouraged driver developers to merge their code as early as possible, even if it doesn't work yet.

Communications regarding wireless drivers, it was agreed, would remain on the netdev mailing list for now. If, at some point, that conversation threatens to overwhelm other traffic on netdev, a new list can be created. There will also likely be a web set put together for wireless driver information in the near future.

Other issues

One purpose behind the summit was simply to try to pull more of the relevant developers into the wider kernel process. To that end, there was a talk on source control systems - git and quilt in particular. The "merge early" approach was advocated many times.

Stephen Hemminger gave a talk on the state of the bridging code. Bridging is of interest to wireless developers - it can be used for connection sharing and mesh networking applications. To that end, the bridging code is likely to be reworked and much of it moved to user space. Just like routing is mostly handled by user-space daemons now, bridging management - including the spanning tree maintenance - will move to user space in the future.

Some representatives of the Personal Telco Project were brave enough to compete with a delivery of pizza for the developers' attention at lunch time. These folks have put together a network of over 100 Linux-based free wireless hotspots around Portland. They had a number of requests of the kernel developers, including free Atheros drivers which don't crash the system and good, zero-configuration mesh networking. This is an interesting project which shows the power of what a few "unemployed geeks" can do.

Overall, the wireless summit was an optimistic event. While the shortcomings of Linux wireless support were well recognized and understood, there was also a clear sense that not only could the problems be solved, but that many of the solutions were already well advanced. If all goes according to plan, the day when Linux wireless "just works" is not that far off.