OLS: The state of Linux wireless networking [LWN.net]

By Jake Edge
July 30, 2008

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.

(Log in to post comments)

OLS: The state of Linux wireless networking

Posted Jul 30, 2008 17:12 UTC (Wed) by salimma (subscriber, #34460) [Link]

I agree; the situation for laptops is quite straightforward, as the chipset vendor is normally
listed (Apple does not provide that information, but the information is otherwise obtainable).
The problem is with those PCI cards, where the card maker uses an off-the-shelf chipset, and
might switch to another vendor without changing the card's model number.

OLS: The state of Linux wireless networking

Posted Jul 30, 2008 19:26 UTC (Wed) by proski (subscriber, #104) [Link]

I think such business practice should be outlawed. It's not like the card vendors would run out of numbers. If they sell, say, a card called G540 and decide to switch the chipset, nothing prevents them from calling the new device G541. Well, perhaps they will need to pay for new boxes and labels. But if it's not done, the customers could end up buying a worse and incompatible device based on the ratings and positive feedback for the original device.

Using revisions is not enough. The revisions are not normally listed on the box or in the listings of online retailers.

OLS: The state of Linux wireless networking

Posted Jul 31, 2008 23:59 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

Yeah, it's a trademark violation by the owner of the trademark!

I suppose a company that does this will tell you the parts and fundamental design of the product are a minor part of what makes it a G540. And that the reputation of the G540 comes from the skill of the company's engineers and builders and its customer service.

OLS: The state of Linux wireless networking

Posted Aug 1, 2008 12:58 UTC (Fri) by jamesh (guest, #1159) [Link]

Of course, for most retailers and customers the two devices are identical: they both let a
Windows box connect to a wireless network.  Giving different model numbers just adds
confusion: how is the G541 better than the G540?

And if I am a retailer, having the vendor change product numbers all the time would be a pain:
how will I get rid of old G540 stock when the G541 is on the shelves too?

OLS: The state of Linux wireless networking

Posted Aug 2, 2008 5:20 UTC (Sat) by proski (subscriber, #104) [Link]

Customers will install different drivers, even if they don't see the difference. However, it's likely that the drivers will have different bugs.

One device is not necessarily better of worse for a particular purpose. For instance, support for 802.11a is irrelevant if no 802.11a APs are used. However, some customers (and more importantly, reviewers) may discover that a particular device is better at a particular task.

You are right, retailers may not like it. That's why so many manufacturers are doing it. That's why asking nicely is not sufficient.

The issue is orthogonal to Linux, by the way. Even if all users are going to use Windows and the vendor drivers, they are still entitled to be informed of essential changes in the product they are buying.

OLS: The state of Linux wireless networking

Posted Aug 4, 2008 13:10 UTC (Mon) by proski (subscriber, #104) [Link]

P.S. We don't see motherboards switching from Intel to VIA chipset without changing the model number. We don't see desktop systems switching from Intel to AMD, but keeping the model number. We don't see video cards using ATI chipset in rev1 and nVidia chipset in rev2. Retailers and end users can deal with it somehow.

It is pretty much expected that changing the main chip would make it a different model. Wireless OEMs are misusing our trust. They should not be allowed to get away with it.

OLS: The state of Linux wireless networking

Posted Jul 30, 2008 17:55 UTC (Wed) by jebba (✭ supporter ✭, #4439) [Link]

This list may help:
http://www.fsf.org/resources/hw/net/wireless/cards.html

OLS: The state of Linux wireless networking

Posted Jul 30, 2008 19:22 UTC (Wed) by rpil2 (guest, #49526) [Link]

It seems a reasonable start, but it's not exactly user-friendly.

I would think that most people want to know either

1) I have a piece of hardware, does it work with linux/how do i get it to work?
(ie what features are supported? what modules do i need? what kernel/distro version do i need)

or

2) I want to buy a piece of hardware, what (supported) options do i have?
(ie which models work, where do I buy them, how much are they?)

but that page doesn't seem to be very useful for either of those.

In fact, there's a massive opportunity for someone to make a very useful sight to answer those
questions for general hardware

OLS: The state of Linux wireless networking

Posted Aug 1, 2008 0:08 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

In fact, there's a massive opportunity for someone to make a very useful site to answer those questions for general hardware

It seems that way to me too, and I also think it should be easy to gather the data, but I've seen several attempts at this just fail.

And some people have gone further and made a business of selling the actual hardware, warranted to work on Linux. They didn't succeed either.

I can't even find a reliable way to figure out, given that a device I have is usable in Linux, what module to load as its device driver. In the Windows world you can just go to the vendor's website, look up the model number, and grab it.

OLS: The state of Linux wireless networking

Posted Aug 2, 2008 10:56 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

I can't even find a reliable way to figure out, given that a device I have is usable in
Linux, what module to load as its device driver. In the Windows world you can just go to the
vendor's website, look up the model number, and grab it.

Unless the device in question is something archaic, like a pre-PNP era ISA board, or you are
hand-rolling a tiny Linux distro with minimal tools for some embedded hardware - you don't
need to figure this out, the module system will do it for you automatically.

Driver modules contain aliases like (pci:v000010B9d00005288sv*sd*bc*sc*i*) which match the
hotplug events generated when such a device is inserted or noticed at boot-up.

e.g. type 'modinfo ahci' and you'll see it has aliases for a number of devices which we know
support AHCI, plus a line which matches any unknown PCI (or PCIe, ExpressCard, mini-PCI etc.)
device which claims to offer the AHCI sub-class.

When you "go to the vendor's website and grab it" usually you get a bundle which may contain
two or more drivers, and that bundle also contains the equivalent plug-and-play information
for Windows to perform this same driver matching trick, so there's no difference here.

If you mean it would be nice to know where to look on the web for that driver, well, for
ordinary users that's not very helpful because they don't want to download an out-of-tree
Linux driver and learn how to compile it, so they're mostly going to wait until their vendor
includes it at which point it ought to Just Work.

OLS: The state of Linux wireless networking

Posted Aug 2, 2008 18:12 UTC (Sat) by cortana (subscriber, #24596) [Link]

Because I'm always forgetting this information when trying to trouble shoot others' systems...

 1. Find the device in the sysfs. For instance, my wireless network card corresponds to
'/sys/devices/pci0000:00/0000:00:0f.0/'.
 2. Examine the 'modalias' file in this directory.
 3. Run /sbin/modprobe -v -n --first-time $(< /sys/devices/pci0000:00/0000:00:0f.0/modalias).
This shows you the module that will be loaded for this hardware.

You can also do this by hand...

 1. Find the device in the output of 'lspci -nn'.
 2. Note the pair of numbers on the end of the line. These are the vendor and device IDs that
uniquely identify the device.
 3. Look this information up in /lib/modules/$yourkernel/modules.pcimap

The same approaches work for USB and presumably all other modern/sensible hardware.

OLS: The state of Linux wireless networking

Posted Aug 2, 2008 19:53 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

That's great information; I have filed it where there's a chance I will find it next time I have this problem.

I'm in the tiny system boat -- not that I'm working with an embedded system, but it's still more cost than it's worth to include a device driver for a device that there's only a one in a thousand chance I'll ever have. So when I do add a device, I have this exercise of determining which driver it needs (and if one even exists).

It looks like a modules.pcimap from a full, current Linux system is the directory I've been looking for.

Incidentally, an important class of device driver that isn't covered by this is X video controller drivers. I recently changed a video controller, on what I think is a fully conventional Debian system, and it was a more-painful-than-Windows experience getting Linux (i.e. x.org) to work with it. And even then, it would not do DVI, which I eventually concluded is because Linux driver software that can do that simply doesn't exist. That's an example of the problem that started this thread: How do you know what works and what doesn't on Linux -- even with modules.pcimap?

OLS: The state of Linux wireless networking

Posted Aug 2, 2008 20:23 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

The X video drivers are also supposed to be auto-selected based on a similar principle. You
don't specify what type of video hardware you had, so we can only speculate as to why it
didn't work but you don't need to configure modern X servers to make them work. Without a
configuration the server should detect your PCI/AGP/PCIe etc. graphics chipset and load the
appropriate driver, and the driver should (if your display is switched on) pick the right
output and a working video mode.

Thus, try removing the configuration file and starting the X server. If this doesn't work in
current X.org, and you have a card which is actually supported at all, you should report it as
a bug, attaching the X server logs.

Annoyingly there are a few things which won't work correctly without a configuration file, but
it should at least be usable and you should consider filing bugs about anything that doesn't
work (I have an open bug about the R400 driver defaulting to XAA then complaining that XAA is
unsupported and suffering some redraw bugs as a result)

The latest chipsets from the major vendors don't work (or work poorly) unless you are willing
to use the vendor's proprietary drivers (and in that case any problems should be taken up with
them). Don't buy stuff aimed at Windows gamers with too much money.

The mention of DVI makes me wonder if you had something more serious wrong though, DVI ought
to work with the hardware-specific drivers for Intel or ATI hardware old enough to be
supported, or even with a lot of nVidia cards - you are seeing text through this DVI connector
prior to X starting, right ?

Linux device driver availability (wasOLS: The state of Linux wireless networking)

Posted Aug 2, 2008 21:23 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

Thus, try removing the configuration file and starting the X server.

I ultimately did essentially that. But if you have to remove a file in order to use a new video controller, you're already in more-painful-than-Windows territory. Especially if you have to find an expert like you to tell you to do it.

The mention of DVI makes me wonder if you had something more serious wrong though, DVI ought to work with the hardware-specific drivers for Intel or ATI hardware old enough to be supported, or even with a lot of nVidia cards - you are seeing text through this DVI connector prior to X starting, right ?

No, I've never seen anything come out of the DVI connector, and I tried every scenario except putting the card in a Windows machine. It's a Matrox G400; the 'mga' driver man page, and some morsels I found on the web, suggest that you have to specifically turn on DVI and the only known software that can do that is a closed source X module from Matrox and Matrox does not offer a version compatible with the X server in my Debian Etch system.

This is just the card that was laying around. But if I had set out to buy something to drive my DVI monitor, I don't know how I would have known what to choose.

Linux device driver availability (wasOLS: The state of Linux wireless networking)

Posted Aug 3, 2008 9:13 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

Well, I guess my point was more that the distro oughtn't to create this file in the first
place. One of X.org's biggest problems these days seems to be the little programs that Linux
distributors knocked together in Perl or C ten years ago that try to create a "correct"
configuration, often at install time. Obviously anything that the distro manually configures
at install time and which subsequently needs changing is going to be a pain for the user.

We can't really blame the distributors for doing this back when XFree86 wasn't smart enough to
just pick a working driver and configure it, but we can blame them for not re-assessing this
decision some time between when X was first able to run without configuration and today. By
the point when Etch was released such a file was necessary for only a tiny minority of users,
and so it should not be written by default.

You won't have to remove the file again - it should stay gone (unless sadly you have to
recreate it due to one of the outstanding limitations of the auto-configured X server, but
fixing these ought to be a priority)

I have to say I did not realise that they made G400s with DVI, I guess it figures given the
niche where Matrox makes money but it was still a surprise to me. My G400 just had a single
VGA output. Yeah, that chipset is not well supported and mine has been in a junk pile for some
number of years. Apparently its video BIOS doesn't enable the DVI output (else you'd see
something) so that means it's not just Linux, any OS without explicit support for that
hardware won't work with DVI on that chip, which is pretty sad.

I don't think there's much chance that anyone will look at a nearly 10 year old chip now and
think "Ooh, reverse engineering the DVI output looks like a fun project for a rainy weekend"
so you may be SOL, sorry. And I can see how you'd feel misled, the G400 is documented as
working, without a caveat about that DVI output.

X configuration files, DVI on the G400

Posted Aug 8, 2008 12:40 UTC (Fri) by anton (guest, #25547) [Link]

Yes, on all the Radeon cards I have tried Debian (and its derivatives) creates an xorg.conf file that does not work, and if I delete it and start X, the card just works beautifully. Its as if Debian and its derivatives were staffed by Nvidia employees.

Concerning the Matrox G400, I used to use a G450, and its DVI output has a rather limited bandwidth that allows only 1280x1024 with regular modes. I used a special mode to make it display 1600x1200.

OLS: The state of Linux wireless networking

Posted Aug 4, 2008 11:26 UTC (Mon) by daenzer (✭ supporter ✭, #7050) [Link]

> (I have an open bug about the R400 driver defaulting to XAA then
> complaining that XAA is unsupported and suffering some redraw bugs as a
> result)

Which bug report is that? The radeon driver doesn't say that XAA is unsupported but that
RENDER acceleration is unsupported with XAA (on >= R300 cards). As for XAA rendering
corruption, make sure its offscreen pixmap support is disabled (the default in current X
servers).

OLS: The state of Linux wireless networking

Posted Aug 2, 2008 20:04 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Ooh, modalias, I did not know that was there. I knew about modules.{pcimap,usbmap} and so on,
but not the sysfs modalias feature. Neat.

OLS: The state of Linux wireless networking

Posted Jul 30, 2008 23:38 UTC (Wed) by mmarsh (subscriber, #17029) [Link]

That happened to me -- I returned the card to the store.  It helped that I already had an
802.11b card, so all I lost out on was the faster speed, rather than desperately trying to get
it working with ndiswrapper.