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
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!?
Perhaps you should have found out the dismal support part before you purchased the adapter. Duh.
Which one? The Belkin F5D7050 has GPL drivers from the chipset manufacturer for Linux, Free/Net/OpenBSD, Mac OS X, and Windows.
http://ralink.rapla.net/
Why don't you just write your own driver? I mean, it's not like you have a life, or a job, or even classes to attend. Everyone else gleefully looks forward to debugging code on poorly-documented (or undocumented) hardware released by manufacturers who really coudl care less about Linux support. Everyone else here is well-versed in C, C++, FORTRAN, COBOL, Pascal, Java, Perl, CGI, and Python. And just because the command line interface is byzantine and cryptic doesn't mean it's not appropriate for children, grandmas, and Linux newbies of all ages. After all, if you haven't memorized the entire vi command set, you're just not worthy of using Linux yet.
/. response to anyone who points out the elephant in the living room, namely that while Linux does lots of complex things very well, it's the easy things (or at least the things Windows makes look easy) that are turning off potential converts. After all, if even knowledgeable people have to wrestle for hours to get a damned USB device to install properly -- a device that will install flawless in under thirty seconds on a Windows machine -- just how many new users does Linux really expect to attract?
Now, the preceeding sarcasm has been brought to you by someone who uses Linux on a fairly regular basis and depends upon it to run more than a few servers in my enterprise. Yet I am consistently un-surprised at the typical
Are we really all satisfied with this level of user accomodation in Linux? It sure seems that way most of the time.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
I had the same problem at first. I'd picked up a Netgear WG311v2 at Fry's and it took me *forever* to finally get my card working that first time. "Craig's ACX100/111 Guide for Linux" was extremely helpful if you've got hardware using this chipset. (I'd link to it, but don't want to slashdot them or anything.)
The driver was flaky, but functional. Now I've updated to the new driver at acx100.erley.org. Again, it took quite a bit of doing to get it working the first time (documentation for the new 2.6-only driver isn't as good yet), but now that I've gotten it working it's ROCK SOLID. It Just Works.
Well, as much as anything that required recompiling the kernel can Just Work, anyway.
It's basically the same story as with winmodems (no hardware specs), but the Linux community is further along in reverse-engineering because it's... well, it's WiFi, damn it, and not just an easily-upgraded internal modem.
Speaking of which, my brother can't get Linux to see his winmodem on his Compaq Presario laptop. Any pointers?
Graham "Teach" Mitchell, computer science teacher, Leander HS
Well, considering Microsoft doesn't ship a new 'stable' kernel (that isn't even remotely stable) every four months.... no, it's really pretty easy to develop for.
Well, that might be a useful yardstick if the reason why was that the Linux Kernel API changed every four months, which it does not. But I still think my original point is valid. Both are still being worked on, and both are therefore moving targets. To say Windows is not a moving target is laughable.
Remember the API change when MS moved to WDM? How about the differences between NT and 9x? Or the proposed Longhorn changes? How many drivers changed from 2000 to XP? How many things broke or needed tweaked when XP launched SP2? Windows is every bit as much of a moving target as any other work in progress. The whole "Linux is a moving target and windows isn't" is observably wrong.
Weaselmancer
rediculous.
You raise a good point here. MacOSX is good/better than any other *nix variants simply because the hardware is basically locked to what Apple wants to use. While Linux (like Windows) has to work on the widest variety of hardware, MacOSX does not.
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.
I think the story submitter wanted practical information, not to partake in the blame game. Here it is: WLAN support is abysmal on Linux compared to that on Windows or OS X. You'll be hunting for driver support (if it exists) or spending a couple hours fiddling with ndiswrapper. Pile on the routine annoyances of Linux (the handful of commands necessary to connect to any AP) and you'll get frustrated quickly. No sugar coating; WLAN on Linux sucks.
Yes, we all know that blaming the establishment is very convenient for avoiding the truth. But please, the submitter didn't want to argue; he just wanted some facts.
Hate to burst your little bubble there, but Linus != God.
A vendor can get *nix support without spending a dime--just publish enough specs for other people to write the drivers. Individuals will happily write drivers around every little kernel-build quirk. Sure there's that whole FUD-nugget of "our competitors will steal our trade secrets if we talk about them openly!!" But we're talking about freaking wireless chipsets. Frankly, I could care less if my laptop's wireless card is a whitebox 802.11g or the top of the line SkinkFish 802.11g Super-Dooper-ExtreemoVision with Multiphasic Shields (tm). I'll still only get 5 mbits max most places.
I shouldn't need to spend $25.00 for a car charger every time I get a new cell phone, nor should I need to recompile the kernel everytime I switch brands of some random computer device. These interfaces have all been standard for quite a while now. We should hold our vendors' feet to the flames and simply not buy products that have this sort of lock-in built in, IMNSHO.
...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!
1 - Many manufacturers switch chip sets without switching card model names. You can check the compatibility list, buy a supported card and find out when you plug it in that it is not supported.
2 - If you buy a laptop with built in WiFi, you're stuck with the chip that the manufacturer selected. You can hope to get it working with something like ndiswrapper, but that doesn't always work.
I've had mixed results. First cards I bought were Orinoco 802.11b silver cards and they worked pretty much on the first try after I found the wlan drivers. Likewise with the Intel wireless built into my Thinkpad T30. Up until the latest Windows driver download (2 days ago) the wireless on my Thinkpad worked better under Linux than Windows XP.
Then I bought a card that was supposed to have a Prism chip but turned out to have a Realtek chip. They provided support for 2.4.20 and 2.6.? for Redhat. I got the 2.4.20 version working with Debian and became bound to that kernel rev. As linux kernel versions came and went, the vendor never updated their driver. I also found an Atheros based chip that worked just great with the Madwifi drivers.
My most recent laptop is an AMD Turion from HP. I was not able to get the built in Broadcom WiFi until ver 1.5 of ndiswrapper was released.
Comment removed based on user account deletion
If the drivers are buggy, who the hell do you think gets blamed?
The...people...who...wrote...the...drivers?
You really think people track down that little known Korean company that actually made the hardware when they've got some BSOD in Windows?
Again, tossing some source into the wild and hoping for the best is not how businesses work. If they decide to support a product, nearly all of them want to do it well.
You're confused.
People are asking for access to the same specifications that they have to put together to have their own software developers make drivers for Windows, or in some cases, to obtain federal licensing permits, and etc.
They are not asking for "some source from the wild", they are asking to understand how the hardware works.
As I understand it, the reason a lot of manufacturers won't open up the specs for their chips is because they're cheap software controlled radio tranceivers; where the only restriction on the radio frequency used, is the software itself. This is what I've heard anyway. Whether it's true, or not, I couldn't say; if it is then it's moderatly understandable as to why they're unwilling to open up their specs.
Yeah, I had a sig once; I got bored of it.
Again (for about the third time, I realize)... that's not how businesses think. If you're going to support a given platform, you do it WELL. That means testing. That means QA engineers.
And exactly what is stopping businesses from supporting, testing, doing QA, and releasing the source of the driver to merge it in the main linux tree? That's how you do things "well" in the linux land. People like 3Com, Intel or adaptec are releasing AND maintaining drivers for their devices in the linux tree TODAY (there's a reason why I keep buying intel stuff...).
Let's stop this: Companies CAN support linux if they can. They're companies doing it (check the linux kernel mailing to see people from different hardware companies sending patches). Supporting linux is possible TODAY. Most of the companies just DON'T bother
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!
True, however some distros do put on patches that can mess things up. Also it would be nice to see some companies actually package their drivers for new users, and that does need to be done individually for each distro.
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.
As I said to another person, a disgruntled customer (someone I broke a promise to) is a hundred times worse than someone who isn't a customer at all. Someone who isn't a customer may still buy things from me. Someone who's mad at me won't, and will damage my business by telling other people I suck.
Much better to just not make the promise.
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."
The people marking things flamebait in this thread are doing Linux a real disservice. It's not perfect. Recent changes in the development model have messed it up. And simply pointing this out IS NOT FLAMEBAIT.
Metamods: the marking of the parent as Flamebait was Unfair. Please mark appropriately.
The best advice is to just look at /usr/src/linux/drivers/net/wireless/Kconfig, and pick a device with one of the chipsets listed in there.
The real weak spots in Linux drivers are for dialup modems...
/dev/dsp directly.
I have been using Linux for 11 years, the whole time using dialup, with many different machines, and I never had a problem with a dialup modem. All of them simply worked out of the box, no configuration required. I used to run dual boot with Windows, and at least two of the modems that I had, that ran perfectly well with Linux, simply completely refused to work with Windows, and for several other modems I had to download drivers and configure them. Linux does have hardware issues, but dialup modems are not among them.
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.
Ehm, and what about the several sound servers that exist? This is simply bullshit. The only problem is with older applications that use
Also, there would be stable ABIs for drivers and applications (which only removes the freedom to change the architechture BETWEEN major OS releases).
Oh no, not this old tired mantra again. It has been discussed over and over and over, and it's getting really boring.
AccountKiller
Applications using alsa doesn't suffer such problems. Stop using apps that use /dev/dsp directly....
OK so you want developers to break compatability with non-Linux platforms and you want users to abandon their software and just use something else (ignoring the fact that in a lot of cases "something else" doesn't exist, is broken, unreliable, unsupported, etc)?
Makes sense... And after all, people porting code to run on other OS's *really* enjoy re-writing huge chunks of Linux specific junk...
You mean, "with Linux (x86)"? Hacks are not the solution in the long term. We need open drivers, and at least freely distributable firmware files (if not open ones because of regulation).
Of the 802.11g hardware (pci/usb/pcmcia), Symbol, Zydas and Atmel allow firmware distribution with okay terms, people should support them. Also, Ralink, Atheros and Realtek have cards that do not require the firmware to be distributed. Intel, TI, Conexant and Broadcom should be boycotted for their stupid policies of not allowing eg. Linux distributions or BSDs to distribute the firmware files without specific agreement (which they can choose not to make). Yes, even Intel though it has nice drivers otherwise.
Driver situation varies, but as pointed out eg. RT2500-based cards (see http://ralink.rapla.net/) are a good choice, as are probably Atheros-based cards (madwifi) and Atmel-based cards. Zydas drivers, even though GPL, have been unstable for long, even though there are both a manufacturer-provided GPL driver and a community-supported one - the co-operation just hasn't been fluent until perhaps now.
And it has to be remembered, that even the freely distributable firmware file is not currently the optimal solution, because it's a binary blob with no source and there are no rights to modify it. But perhaps we just have to live with a few "restricted" blobs (like the terminology in Ubuntu) when it comes to the hardware firmwares - our graphics cards also have closed firmwares etc. At least a device firmware is a lesser threat to freedom than closed drivers like the binary graphics drivers.
Buyers need to check for compatibility first, before blindly going out and spending money on the first thing they see. Buyer Beware.
Maybe then the manufacturers will begin to listen.
against the fritz!wlan usb stick which has sourcecode drivers for linux directly from the vendor
also good are the intel 2100/2200 chipsets for wlan, and as you had seen the prism ones.
also check the kernel sources for more supported wlan usb sticks, as i myself prefer to use pcmcia/internal chipsets
never needed ndiswrapper, i have d-link, compaq and intel wlan chipsets here at use, and i had installed the fritz!wlan usb stick for a friend on linux