Slashdot Mirror
State of WLAN Support on Linux?
ntropic asks: "I/ve recently bought a Belkin 802.11G USB adapter and was dismayed to find, after a few hours of struggling with it, that there seems to be no one who has managed to get it working under Linux. During the search for clues, it seemed that sum total of Linux support for wireless networking are the linux-wlan project, and the linuxant wrappers for Windows drivers. The former seems to support only Prism chipsets while the latter is a commercial solution, albeit quite an inexpensive one. Is that all, or are there better sources for wireless networking support?"
http://ndiswrapper.sourceforge.net/ Lets you use original Windows drivers on linux. Not pretty, but it works pretty well. Meanwhile, blame manufacturers.
What about ndiswrapper? Have you tried that yet? Some distros have ndiswrapper built/shipped with them. (SUSE does, IIRC) You'll have particular issues with wireless cards that use Broadcom chipsets - Broadcom won't release info about the chipset to any open-source groups. However, if you can get your hands on and can compile ndiswrapper for your machine, it should work well. Ndiswrapper has come a long way since I first tried it, and it's the only way I can use the Broadcom AirFoce 54g on my Acer laptop.
I've used the Linuxant software in the past when ndiswrapper failed me. The support was excellent and they support almost any wireless device you can think of. $20 isn't bad either, for a lifetime license....
As far as the "state of WLAN support", blame the people who build the chipsets (Broadcom, et al) and market forces. If they were willing to either open up the necessary information to linux developers or have their own coders write drivers for linux we'd not have this problem. Of course, if Linux had greater marketshare, we'd probably see more linux drivers as well. This argument goes for most hardware and linux in general, though....
My MythTV HowTo
As long as you don't need WPA, get a card with an rt2x00 series chip. The drivers work fine, though they are not yet good enough to be merged into the kernel. http://rt2x00.serialmonkey.com/
Manufacturer won't release information on hardware. So the only way to find out how to interface with it is to reverse engineer the windows driver, a tedious enterprise. If it's really an issue, return the product and tell the retailer why it is being returned. Enough people doing that, the manfacturer will have to bend if it wants the business.
ELOI, ELOI, LAMA SABACHTHANI!?
Not sure what chipset your wireless card uses, but if it's Broadcom, there are 2 solutions now. 1) http://ndiswrapper.sourceforge.net/ lets you use Windows drivers on Linux. 2) http://bcm43xx.berlios.de/ the native Broadcom driver is stabilizing now. It's experimental at this state, but people are using it on both x86 and ppc. I think you have to have a 2.6.15 or later kernel to use that though. I'm still using ndiswrapper for mine, it works okay until the native drivers are stabilized more.
802.11g under linux is sort of a mess. Wireless cards are getting cheaper and cheaper (in terms of manufacturing) and much of this cheapness is cutting corners, taking more logic off the cards and putting it into software (drivers/firmware).
The vast majority of 802.11g cards out there are almost entirely controlled by software. The frequency, transmit power, etc. I believe the specs to this are all goverend by the FCC (in the US at least, I'm sure most other nations have their own governmental bodies governing what can and can't be done).
As such, opensource drivers are tough as you don't want anyone just modifying the code to change frequencies, up transmit power etc. Also, a number of manufacturers have used "competition" as their reason for keeping things closed.
As a result, the support out there is lumped into a few different chunks:
1) no drivers available
2) atheros drivers (contain a binary HAL object file. This allows them to have a small source component that people can build that links against the binary object which contains the routines to do the various things I mentioned above (basically control the card)
3) opensource driver + firmware (where the firmware component does what the HAL does, but since it's actual firmware loaded to the card, it allows the driver interface to be fully opensourced without revealing too much of what's going on. The intel and prism54 drivers are in this camp.
Basically, if you don't have a prism54 or intel based 802.11g card, you can't use open source drivers, and the drivers will never be included into the kernel because they can't be open sourced. Atheros was nice to release their stuff so that at least their cards are usable.
Every other manufacturer's card users need to hope that their mfg is nice enough to do what atheros does (or if their driver is firmware based, do what intel/intersil[or whoever owns the prism54 stuff now] did by either writing drivers, or helping with it.
It makes it tough if you don't know this ahead of time, but really with 802.11g, you just need to pick the right card and hope. Unfortunately none of this is really very well documented.
Absolutely untrue. Madwifi has support for a ton of b/g chipsets based on Atheros stuff. You can pick up a nice DLink DWL-520 for cheap, and it'll work great. (at least, that's what I think i picked up a few months ago... its something like that, at least).
That's because ndiswrapper is included with Suse 10, but not with knoppix or kubuntu.
Let's make sure we take a chance somewhere in this list to thank the developers who've made it possible to use ANY wireless NIC with Linux.
Thanks guys.
You aparently didn't come across the biggest Linux wireless site that I know of.
n ux/
:)
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Li
The only wireless device that I haven't managed to make work is the Broadcom BM4306 that came with my HP zv6000. That's not a failure of the Linux drivers. There is a stupid soft button to enable the antenna, and no one has figured it out for this particular zv6000 subrevision. All my other wireless cards work fine in the PCMCIA/PCCARD slot.
As I've found, if all else fails, get a wireless bridge (like a Linksys WET54G), and plug it into your ethernet port. Sticking on one extra device is a lot easier than switching to Windows.
Serious? Seriousness is well above my pay grade.
Atmel and Realtek, I believe. With WLAN, you really have to check which chipset you get before buying. Avoid Broadcom, Prism54 (driver support is coming, but depends on reverse engineering). Here is a page with some recommendations.
Personally, I have an Asus WL-107 with Ralink rt2500 chipset (cardbus), which works acceptably, and a 3com with Prism54 that doesn't work. Beware of cards that change chipset from revision to revision.
Why hasn't anyone else linked to this chart which aims to be a complete list of wireless cards and what driver, if any, they're supported by under Linux?
:)
It's incredibly useful.
Personally, I've had bad luck playing with the bcm43xx driver a few weeks ago, and I've loved the new version of the ipw2200 [finally the 1.0.[78] bugs are gone!] and my rt2x00 card is a nice backup.
Also, ndiswrapper works fine, provided you use 1.8 if you're on a 64-bit system.
It's only an insult if it's not true.
That said, the state of Linux wireless networking today is similar to where its wired networking was say six or seven years ago -- a few solid drivers, a bunch of drivers that sorta work, and a bunch of drivers with promise but very experimental. When I bought a wireless card I took care to get one that I could find Linux native drivers for, an MSI US54G based on the Ralink RT2500 USB (RT2570) chipset. (The Ralink drivers are the basis of the rt2x00 project, which claims that the next-generation unified driver will do everything and make your coffee too, but last fall it was just getting to the point where you could associate to an AP). The situation is complicated by the fact that different versions of the same model card from the same manufacturer may have completely different chipsets -- not all Belkin F5D7050 adapters are Ralink-based like my wife's is. And even if you have the driver for the chipset, the device itself may be on a PCI ID the driver doesn't look for by default, necessitating a quick patch and recompile (I had to do this for my US54G to get the rt2570 driver to recognize it). Or the driver may not be preemption-safe, locking up your system when you up the interface unless you compile a custom version of the kernel without preemption enabled. There's a million niggly things you may run into, but most of them can be worked through or around in some way.
As time goes on, the good experimental drivers and the existing reliable drivers will develop full feature sets, the bad experimental drivers will be left in the dustbin, and it will become more common for manufacturers to follow Ralink's lead and open-source their drivers.
One reason for the lackluster support on many chips is that apparently US companies are bound by FCC regulations not to allow the TX power on their adapters to be boosted beyond a certain threshold, so e.g. Intel releases a Linux driver with a binary-only firmware file. If you look at the installation info for some wireless hardware (802.11a, I think) it will even say only FCC-certified installers can install the card in a host device (because of concerns about improper installation causing harmful interference). So there is a certain point beyond which manufacturers may never go and the community will have to reverse engineer if they want those drivers to be fully open-source (and said drivers may be illegal to use in the US or other places).
And if you want security on your network, oh boy, the fun you're going to have with wpa_supplicant (assuming it supports your card at all...)
-- Old Man Kensey
I'm guessing you don't know a whole lot about Linux driver development. I'm not being snarky, it's just your comment seems to indicate that.
Plus, Linus' kernel isn't stable. He just waves his hand in the air and announces that 'the distros' will have to make Linux actually work. That means that now we have Red Hat's kernel, Suse's kernel, Mandrake's kernel, Debian's kernel.... and they are all running different versions and patch levels, and each will have different assortments of bugs.
This is not really the case. Even though different distros do things differently, the kernel API remains the same. The only time the API changes is when Linus says so. And that usually happens on even numbered releases (if at all). You will typically see Linux drivers advertised that they work with the 2.4 or 2.6 kernel. Occasionally 2.0 kernel for legacy stuff. And that's pretty much it. Not a terribly difficult target at all. And certainly not harder than Windows.
Weaselmancer
rediculous.
Notice that vendors are not being asked to modify the drivers in each release. We're asking them to release open source drivers - "we" will do the neccesary job to integrate them and maintain them in the kernel. Hell, release drivers even if they're against a 2.4 kernel, people will port them to 2.6, it won't be easy but it's certainly easier than reverse engineering or writing the driver from scratch (unless the drivers is a complete crap)
So the "unstable API" has not sense. By the way, notice that the kernel API _is_ stable: for a single version. No, this is not a joke: The new development model implies that EVERY kernel release is a mini-development kernel which can be stabilized in ~2 months. In other words, make progress slowly, gradually, instead of big development releases which are a pain to manage and stabilize, because there're thousand of new things instead of just a couple: It's much easier to find bugs when there're few important changes. Also the new kernel development model forces people to test things and develop production-ready code after testing it in the -mm tree, in a typical development model people tends to care less about making things stable until the "stabilization period" starts. Call me stupid, but I like this model.
...something friendly and easy to browse when shopping for hardware. Why distro vendors are not collaborating on maintaining an HCL site is a mystery to me, as it would be a powerful tool in persuading HW vendors to offer support.
/rewarding/ manufacturers that don't support Linux.
There is one at Linuxdevices.org, but its just a glorified messaging board and mostly out of date anyway.
I also find it unsettling that Linux users keep buying peripherals without checking compatability first, and end up
The real weak spots in Linux drivers are for dialup modems and Wifi cards. And Bluetooth adapters. Oh and Intel video is still broken.
Soundcard support is pretty decent, until you realize the OS often implicitly locks-out multiple apps from outputting audio... so uses involving alerts and alarms (timers, calendars, IMs, softphones, etc.) cannot be relied upon. Obviously this is also an obsctruction for musicians and DJs. But ya gotta maintain compatability with 1991 apps so the brokenness stays.
No one below the GTK+/Qt layer is paying attention to desktop use-cases, and those GUI developers are left helpless on many issues because of it. Otherwise I would not have to write the above paragraph about audio. Also, there would be stable ABIs for drivers and applications (which only removes the freedom to change the architechture BETWEEN major OS releases).
As for NDISwrapper... Thank you Microsoft, for providing a stable ABI that allows me to use my USB Wifi card on Linux!
Comment removed based on user account deletion
For the love of Dog, don't just go out and buy any old crappy wireless card and hope that linuxant or ndiswrapper will support it. All of these slashbots who recommend this route are just remorseful that they didn't do their research before wasting their money on a monopoly-sustaining wireless card.
The worst part is that ndiswrapper and linuxant usually don't allow full use of the card. Sure, you can probably get some connectivity out of it, but sometimes you can't use 802.11g, put the card into promiscuous mode, or use one of the fancy wifi signal-strength and network information applets in KDE and GNOME.
When people ask me about Linux wireless support, I tell them two things:
1) Skip on down to Staples and pick up a Netgear WG511T. It'll cost $40-$50 depending on where in the nation you buy it and what rebates they have going at the time.
2) Boot your favorite distro and install the MadWifi drivers. Configure ath0 for DHCP, sit within range of an access point, and you're good to go.
The madwifi drivers work with Atheros chipsets and evidently Atheros themselves contributed a large amount of the code, so it would be in the interest of all Linux users to support them by checking out the MadWifi compatibility listing and purchasing one of the listed cards. You'll be helping the open source community and getting the most out of your wireless card at the same time.
You have absolutely no idea what you're talking about! How on earth did this get modded up!?
There is only the Linux kernel... and no you don't have to develop a driver for multiple versions of Linux! That's nothing short of absolute lies!
If it's one thing I hate it's an anti-Linux zealot that doesn't even know what they're talking about. At least take the time to learn about what you preach against.
A point by point rebuttal of everything you said:
But first let me point out that I've actually written device drivers for both Windows and Linux, I am an open source software author, and I've played parts in writing large applications for big Windows shops. I run and use Linux and Windows on a daily basis... something you have obviously never done.
So here goes...
Windows moves *slower*. When you're writing drivers, slower is demonstrably a good thing.
Windows does not move slower than Linux. The driver API changed significantly with NT, then with 2000. It's been largely stable since then, but there are still continuous changes. It's a complete misnomer to suggest otherwise.
By the same token, the Linux API isn't as unstable as "keeping the API open" suggests. There are many drivers available in the kernel that have been there for... a LONG time. Most of them were ported to 2.6 with no trouble at all.
As a person who has written device drivers I can tell you that writing and maintaining a Linux driver is significantly easier. The docs and community support is all there, and everything makes sense. It's pretty much the opposite when it comes to Windows driver development.
Trying to maintain a driver for Linux would require constant attention.
Simply not true. And the beautiful part about Linux is that even if a driver does need updating, there's a significant chance that if the driver is used by enough people, some person will just fix it on their own. But let me just reiterate that this is completely untrue in most cases. At least not any more than it's true for Windows.
Plus, Linus' kernel isn't stable. He just waves his hand in the air and announces that 'the distros' will have to make Linux actually work. That means that now we have Red Hat's kernel, Suse's kernel, Mandrake's kernel, Debian's kernel...
I'm sighing right now. Why... where do these idiots come from? And how do they get modded up!? Linux is a kernel. It's not an operating system. Nor is Red Hat, Ubuntu, Gentoo, etc... they're distributions of an OS that uses Linux as its kernel.
I've built Linux From Scratch a few times, so I'm painfully / joyfully aware of what this actually means. You're obviously confused about this point so I'll explain it to you.
Basically no matter what distro of Linux you use... you are using your own customized version of a Linux based OS. It may not seem like it when you've first installed it, but it's still true. By the time you get to know what you're doing your OS is probably inherently different than even some other person using the same base distro. You've installed different packages, maybe compiled your own apps and installed them wherever you feel like it. Customized start up scripts, etc.
Whether or not you see that as a benefit is up to you. But let me tell it is a great benefit, and that's what makes Linux so great! That's why there are so many flavors (and no there's not just 5, there are literally hundreds). Choice is what makes it so great.
Imagine a world with 5 automobiles that were supposed to fit everyone.
Anyway... getting back to the point. So you've got all these infinite numbers and possibilities of Linux based OSes out there. Driver hell? I don't think so. This doesn't mean the kernel is any different and it doesn't mean writing a device driver for Linux has to be re-done for every OS, distro, or any other such nonsense.
it means any commercial entity has to develop separate driver
It seems to me that there is confusion about *source* compatibility and *binary* compatibility.
Source compatibility of Linux has been pretty good, with changes only occurring when Linus waves his hand on an even numbered release (for the most part.)
Binary compatibility with Linux is *horrible*. Structures change all the time. Pretty much you need to recompile your drivers even when a *patch* to the kernel is made. Yech!
Open Source developers usually don't care, and Linus has made some pretty vocal arguments against having anything *but* Open Source in the kernel.
Now folks complain when certain hardware developers don't release *open source* drivers. Well, let me tell you, a lot of times there is a lot of proprietary information in those drivers, and the vendors have a vested interest in keeping the drivers closed. In the specific case of WLAN mentioned here, they might even be legally obligated to stick with binary drivers (e.g. due to FCC regulations about software radios.)
Well, the answer to getting better hardware support is quite simple, but it requires the Linux people to change their way of thinking. That is that you need to support a robust kernel API, that provides support for binary compatibility. Its not hard to do -- Solaris has had it for many years. I can have a single source, single binary, that works across a decade or so of Solaris releases without any problem at all, as long as I stick to the documented DDI. Sun has even provided compliance tests to prove this (DDICT).
How you get to binary compatibility involves declaring certain structures off limit for direct access (use accessor routines), stabilizing at least parts of others, and possibly adding versioning interfaces in key places.
Easy to do? Yes, not trivial, but not exactly hard either. Will it happen? Not likely, as long as the GPL fanboys/fangirls insist that binary device drivers are evil.
Now for WLAN stuff, you have another problem, which is supporting userland tools. There are a variety of userland tools for WLAN configuration on Linux, and frankly they were all horrible the last time I checked. Any company that wants to support "Linux" (as opposed to "RedHat 5.2" or somesuch) is going to have to either test a wide range of tools, or supply their own. In this case, choice really has amounted to duplication of effort, and it would be far better to have a single, robust, friendly toolset than the half-dozen odd pieces of junk we have today.
Well, I'm glad somebody finally came out and said it. That's been my experience also.
I have a HP Workstation with what I thought was a Linux-compatible WL PCI card in it, of course when I got the card home and out of the box, I read the small print -- this was the "new and improved" version 3, and only versions 1 and 2 were compatible with native Linux drivers.
So I'm stuck using ndiswrapper. Which does work, just not very well or conveniently. Changing from one network to another is a 10-minute process involving multiple "coffee breaks" (click on something, wait several minutes) and a full reboot. That's right, a complete reboot -- on a system which otherwise never, ever gets rebooted. I'm just glad it's not a laptop, at least as a desktop this setup is usable, since the network's SSID never changes.
To say that Linux wireless is a little "rough around the edges" (this seems to be the party line on a lot of forums) is a bit of an understatement, in my opinion. It's terrible, and while I do blame the manufacturers for producing undocumented products, its the users who end up holding the bag and Linux that ends up looking bad.
Here's my thought for a 'solution,' or at least a stopgap: the problem isn't that Linux-compatible WL cards don't exist, it's that they're very hard to find and poorly marked. (Witness my "v3" problem.) What somebody with a lot of money needs to do, either an enterprising individual or an organization, is find a manufacturer that makes a well-supported WL card (one that uses a Prism chipset, probably) and contract to buy a production run of them in OEM packaging. Call them whatever you want, toss them in a white box with a driver CD, and sell them for $20 more than they cost.
The community doesn't need support for every brand and flavor and revision and chipset of WL card out there. What we need is one card that's available for more than six months that's easy to get ahold of and actually works. The Linux hardware review sites do part of this, but they don't really let you actually buy the part -- you're stuck trying to find a source for the correct version/revision card yourself, and SOL if you can't find it (as is the case with many of the older "known good" Prism cards).
As I've said in other posts, look at the other major non-Windows platform and the reputation it has for wireless connectivity -- the Mac. Macs only have ONE TYPE of wireless card. They avoid the manufacturer issue altogether by just OEMing one or two chipsets, selling it at a ridiculous premium, and building the driver support into the OS. And it works beautifully; I've yet to find a Mac user who doesn't think that their Airport card wasn't worth the $90 they spent on it. (Okay except for some hackers who want the ability to grab raw frames...)
We can blame the manufacturers all we want, but it's obvious that as a group they're going to ignore the Linux platform. However, there's a demand for Linux wireless cards that actually work without hassle or confusion, and they do exist, they're just hard to find. Somebody with the right amount of capital and connections needs to match the two up.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."