Since our previous peek at the state of wireless networking in Linux, which is moving forward in an excellent fashion, the new unified Linux wireless stack (mac80211) has been accepted into the mainline 2.6.22 kernel. This is the new common base for all Linux wireless drivers. There are no drivers yet that use mac80211, but inclusion in the kernel is a huge step forward. Linux developers are hard at work porting old drivers and writing new ones, and this should attract participation from additional developers who now have a nice unified wireless networking stack to build on, instead of the previous mish-mash.
Another important milestone is the legal ruling that clears the way to use OpenHAL for Atheros-based wireless chipsets. Currently Atheros chips require a closed binary kernel blob supposedly to meet FCC regulations that require certain functions be hidden from end users, who might be tempted to commit deeds of rampant dastardliness such as changing the radio frequency power levels or carrier frequency. This has been well-debunked–the Atheros binary blob includes a sizable amount of functionality that has little to do with FCC rules. This interview with Damien Bergamini, ace wireless developer, sheds a lot of interesting light on the subject:
“These algorithms go far beyond the simple enforcement of regulatory compliance,” he added, “and can really make the difference by extending the operating range of the adapter, improving throughput in various environmental conditions, and reducing power consumption. That is why vendors want to keep these algorithms secret.”
Damien noted that it doesn’t bother him that companies don’t want to reveal all of their source code, “but what annoys me is that they still pretend to provide open source drivers while you only have access to the part of the code that drives the MAC and communicates with the blob.”
So for us excellent end-users, OpenHAL means we’ll someday have complete support for Atheros chipsets included in the kernel, which translates to easier installation and updates, and probably better performance. Not to mention an untainted kernel. Greg Kroah-Hartman says that closed source kernel modules are illegal, and I’m inclined to believe an actual kernel developer who talks to actual lawyers.
The New 802.11n Standard, or, The Young, the Restless, and the E Street Shuffle
The evolution of the 802.11 standard could make a “reality” (not that anything is real about them) TV show, although a rather slow-moving one, with all of its conflict and intrigue: vendors developing their own competing, incompatible standards, jockeying for position on key committees, and trying mightily to have their own technologies adopted as the standard. Inevitably there are losers, who must then figure out how to make it possible for customers to upgrade legacy devices that aren’t very old, or figure out a way to make them happy with purchasing bales of new gear.
802.11n, which is a subset of 802.11, is no exception. This is the MIMO, or multiple input/multiple output standard, which means using more than one antenna to increase bandwidth and throughput, and to extend range. (Don’t confuse it with IEEE 802.16, which is long-range wireless networking, such as the “last mile” link for cable and DSL customers.) Early goals for 802.11n were ambitious, aiming for a 100Mbps WLAN standard by 2005. Here at the tail end of 2007 they’ve gotten as far as Draft 2.0, which was ratified in March 2007. This promises enticements such as 300Mbps and a range of 300 feet or more. Of course these are under ideal, perfect circumstances. If you mix 802.11n with 802.11a/b/g devices you’ll get worse performance. Pure 802.11n networks perform the best.
You’ll see ads boasting about devices being in compliance with “Draft 2.0 N”. You’ll also see evasive ads that say “Draft 802.11n.” That doesn’t tell you anything useful; what you want to know is can you mix-and-match different brands of interface cards and access points, or are you stuck with a single vendor to ensure that they’ll work right and support all claimed features?
The thing to look for is officially certified devices. They should say something like “Wi-Fi CERTIFIED 802.11n draft 2.0.” The Wi-Fi Alliancestarted certifying devices in June 2007, and manufacturers are eager to get their products certified, so you should be able to find a fair number of them in the market already. The Wi-Fi Alliance promises that Draft 2.0 N will be upgradeable to the final, official specification, so (theoretically) you’re safe to start buying new gear.
Does purchasing certified devices guarantee that you’ll be happy? Of course not. The devil is in the implementation, so as always there are good gadgets and cruddy gadgets. Some will work well, some will be more suited for target practice at the rifle range. I’ll be looking out for the good stuff, and see Resources for links to helpful sites.
Linux and 802.11n
What about Linux 802.11n drivers? Currently the only ones available are newborn and experimental. A lot of users are reporting that they can get 802.11n wireless network interface cards running with Ndiswrapper, which is a clever wrapper script that lets you use the card’s Windows drivers on Linux. A number of commercial access points are based on Linux, but so far that hasn’t translated into nice drivers or utilities for Linux users.
I wasn’t able to get any encouraging insights from my usual spies, so I am going to make a Bold Prediction: look to Dell to make the first big Linux 802.11n push. Lenovo already sells the Thinkpad T60 pre-loaded with SUSE Enterprise Desktop Linux, and it supports 802.11n, but it’s a well-guarded secret. If I hadn’t accidentally heard about it I never would have known it even existed. (Just for fun, try to find Linux laptops on Lenovo.com. Ha! Lots of luck.)
As the new Linux wireless subsystem continues to develop, we will definitely see excellent 802.11n support and good FOSS drivers. So we won’t have to use nasty Windows binaries, we’ll be able to build our own homegrown wireless access points, and no more hassles with closed, binary kernel modules. It’s just going to take some time, so have patience; and even better, if you can contribute in some way to Linux wireless development, you will receive a warm welcome.