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.
Perhaps you should have found out the dismal support part before you purchased the adapter. Duh.
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).
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/
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.
OpenSuse 10 recognized and configured my D-Link DWL-G650 PCMCIA card. It might also work with D-Link's newer USB stuff. I'm finding OpenSuse 10 to be the best distro I've found so far to deal with hardware issues...easily. Best Buy sells D-Link stuff and is pretty cool about returns as long as you didn't trash the box.
Flamebait all you want from the moderators reading this belonging to the pure gnu persusian but writing closed source drivers are tough for linux.
Blame the manufactors? Its the FCC that forces them to not give out details to hackers. Many other governments have similiar regulations on what hackers can and can not do to wireless. The government doesn't want people takign down airplanes are terrorists doing espianage on communication equipment.
So they must stay closed source if they are an American company. Many manufactors are now using software and creating win-wlan cards to save money. Remember what happened to linux after modem makers only made software modems? Samething with winprinters that make up the majority of printers today.
Under windows you write once and most likely the drivers will work with future versions of windows unless there is a major upgrade. That is because of NDIS and kernel and software level api's and device driver kits for windows.
We need a consistant and stable abi's and api's for linux so hardware makers can release the drivers for linux. Also old solaris drivers work just fine under solaris10 because of consistant api's and abi's.
I know VIA and several manufactors have requesting to Morton and Linus for this feature even though it divides then linux community.
http://saveie6.com/
If you are simply using Linux because you don't like Microsoft products, you might want to have a wander into the *BSD camp and try out OpenBSD which has excellent wireless support* (see compatability list here - Belkin USB adapters are in there, but check the model number). OpenBSD is an extremely secure free operating system with most of the applications that you can find on a Linux distribution. If however it must be Linux, then try SuSE out - it may have the support you need.
* And excellent documentation, a brilliant firewall, a wonderfully clean code base, superb ports system and super sweet line of T-Shirts! =)
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
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
Every OS has them available freely, it would be a good idea to doublecheck before making hardware purchases for ANY os (Windows excluded).
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.
I have a Belkin 802.11g usb card based on the rt2500 chipset. It works great with the ndiswrapper kernel module. Make sure to follow the directions in the README/INSTALL files. Different versions of ndiswrapper work to varying degrees. I use ndiswrapper-1.1rc1 for the rt2500 Belkin adapter and ndiswrapper-0.10 for the builtin Broadcom adapter on my laptop. It sucks having to use different versions for the different cards, but I just set up a script to change things for me and it pretty much just works. Linux' support for hardware can be hard to set up initially, but once you get it working it usually continues to work (unlike a certain proprietary OS that fails every time the Wind-blows).
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 mean unless you buy the hardware from Apple. A Mac is an Apple product. If you were referring to a Microsoft product you wouldn't says "unless you buy the hardware from Windows".
And come on man. You bought a Mini without AirPort? WTF would you want to muck up the asthetics of a Mac with a dongle?
Mac OS X and Windows XP working side by side to fight back the night.
The network developers have recognised that this is a major problem at present. One of the big problems was that nobody was in charge in effect of wireless! (although Jeff Garzik has done a wonderful job of overall networking devices). John Linville has now taken on the job of sorting this mess out. (http://lwn.net/Articles/167272/ http://lwn.net/Articles/167270/).
Subsequent to this discussion there has been a lot of positive discussion on the netdev mailing list and here are some updates:
* Public git tree has opened now
* WPA patches are getting merged
* Other drivers are getting merged into kernel
* OSDL is having a summit to get together the key players (http://developer.osdl.org/shemminger/blog/?p=29)
I would say the picture in six months to a year will be dramatically better.
If you want to contribute then google the netdev mailing list and jump on in. We would certainly appreciate help!!!
You got lucky. Linux is changing internal structures all the time. You just happened not to have had any changes that blow up your particular module.
USERSPACE is extremely robust and hardly ever changes. If you have userspace code from the darkest days of prehistoric Linux, it'll run fine on a current kernel. But kernel space is changing faster than any human can keep up with, including the kernel devs. That's why you're seeing constant local kernel exploits. They're adding features too fast to consider the ramifications.
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.
There are quite a lot of USB 802.11b/g dongles out there containing the zydas zd1211 chipset, which has a reasonably active GPL development effort based at http://zd1211.ath.cx/, including ongoing work from the manufacturers, and aiming eventually for inclusion in the main kernel tree. My company has had a lot of success using devices with this chipset under linux.
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.
You are lucky. If you had gone from 2.6.9 to 2.6.10 you would see a lot of changes on the internal structure. This is specially painful for RHEL, where you have a kernel that identifies itself as 2.6.9 and has the internal structure from 2.6.10 (thus breaking a lot of #ifdef on source modules).
morcego
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.
I think that many of the chipset makers are afraid of the legal liability that widespread software controllable radios could bring on. I'm actually suprised that some jackass hasn't been caught jamming police or airport radios.
In my part of the World, police radios use frequencies around 470MHz. Radios designed to transmit at 2.4GHz and 5GHz don't tend to work too well at 470MHz. It is not too hard to make a wide band receiver, however wideband transmitters tend to be efficient at a given band and then mostly terrible outside of that. Normally a transmitter designed to transmit of multiple bands, will actually have seperate transmit sections for each desired band. I have an old Yaesu FT-411 2m 144MHz-148MHz tranceiver. I modified it (digital unlock with some soldering) for wider receiver coverage, however this also allowed it to transmit on a slightly wider band. With the provided antenna and precise transmitter tuning, it is crap only a little outside of the intended band.
802.11b/g is close to the same frequencies which many cordless phones, mice, keyboards, microphones, etc work at, and dred of all dreds microwave ovens. My 802.11b card came with a simple spectrum analyzer with the software, so that the user can choose a quiet channel. I can always tell if someone near me or my girlfriend switches on the microwave oven, because connectivity goes to hell and the spectrum analyzer lights go nuts flashing around full power on every single channel. It doesn't help that my AP is quite far away, but anyway I think this shows that the FCC have chosen to lump consumer radio goods into the filthy garbage dump of the spectrum.
The FCC would not lump police radios near the deafening RF roar of the Worlds microwave ovens. Sure they may be sealed well, but only a little of that typically 1kWatt of RF at 2.4GHz needs to get out to mess with devices around the same freq.
I don't know how good 802.11a 5GHz goes. Anyone?
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
If you want wireless now and can't get your AE card to work, there are few options. The Linksys WUSB11 USB 802.11b card works "out of the box" under Ubuntu PPC. You can get that for $10 or so at CompUSA. That is the only USB wireless adapter that I have gotten to work natively in Linux on PPC so far.
BTW, ndiswrapper is x86-only at the moment, so that is why it is such a pain in the neck.
...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!
Some drivers are already implemented in userspace - see libusb.
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
Linus (and others) *do* tweak the kernel API on a regular basis.
Well, "tweak the kernel API" is not the same than "tweak every API in the kernel"
Notice that the huge majority of the thousands of drivers inside the kernel doesn't have any changes at all between releases. It'd be crazy if the kernel needed to modify all the drivers for EVERY release. That's certainly not true. Some of them change, sure - when a given subsystem changes something. It doesn't happen every release. You can check it in the git web interface. Some drivers have not had any commit for MONTHS. In fact most of the commits you'll see in the changelogs are internal driver changes, not changes needed to make the driver work with a new api. Some drivers however (ej: the propietary nvidia driver) need changes. If they didn't put a entire opengl stack inside the driver things would be easier. Who knows.
Of course, that's source. At binary level, everything changes. You can't load a kernel module compiled for another kernel version: There're checks to avoid that: Even for the cases where it could work. Many plugin-based apps (drivers are more like plugins, not "programs built in top of the kernel api") require that too. Linux is not a closed source kernel and we don't want that it becomes one.
Windows XP maintains the compatibility, yeah. They've rewritten the USB stack 3 times or so (just like linux) and they maintain the compatibility for all the drivers supporting the 3 different stacks. Just imagine how horribly complex and hard to maintain and evolce the XP kernel has to be.
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.
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.
The problem I have with the state of WLAN is that there are so many competing projects. It's a real minefield for the noob who just wants their card to work.
The majority of cards are now softmac rather than fullmac, so you need an 802.11 stack in addition to the chipset specific driver. Rather than have one stack we seem to have a half dozen: the sipsolutions stack, the dscape stack, the madwifi stack, etc. All of them have bugs and all of them are configured slightly differently.
Features like WPA require an interface between wpa_supplicant and the driver, and once again there are a half dozen variants. There's the wext interface, the ng interface, the madwifi interface, the dscape interface, etc. The ng deserves special mention because you can't even use iwconfig to set some parameters, it's that different.
Most cards have a binary firmware that needs to be uploaded once after every cold boot and getting those firmwares is itself an exercise in complexity. There are a half dozen tools to extract firmwares, copyright prevents the firwmares from being included with the Linux drivers, etc.
On top of all this, every distro has their own way of configuring the special options required for wifi. None of the distros seem to support WPA in their GUI configurators, so you need to drop to the command line to configure WPA supplicant, and then you find the distros all do it differently. The NetworkManager utility which promises to make this all easy doesn't even support WPA (though it will Real Soon Now).
The state of WLAN on Linux probably won't improve until all the drivers support WEXT, there's a standardised "fwcutter" like tool that knows how to extract every firmware for every supported wifi card, there's decent WPA support in at least one distro, and there's a single goddamn softmac stack.
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.
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
Maintaining a database of all the hardware which works for linux is hard, it'd be asier to keep track of what hardware doesn't work. These days we have MODULE_DEVICE_TABLE: in every module: This exports the list of the IDs that every modules support. Recolect the IDs of all modules and you'd get a sort of automated database of all the devices supported by linux
/dev/dsp directly....
Soundcard support is pretty decent, until you realize the OS often implicitly locks-out multiple apps from outputting audio.
Applications using alsa doesn't suffer such problems. Stop using apps that use
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
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.
Has anybody seen Wyse's front page lately? There is a penguin there I believe. They are pushing the linux based thin clients hard in every roadmap meeting we've had. In healthcare, wireless thin clients are pretty much required - I wonder what their wireless support is like in linux products?
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 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
Ralink is a company which manufactures the chipsets for dozens of popular 802.11x devices. They do indeed provide drivers (and source) for linux:
n _Page
http://www.ralinktech.com/supp-1.htm
they also provide a nice table, with links to the manufacturers
http://ralink.rapla.net/
AND they have an open source project, as well, to support the drivers!
http://rt2x00.serialmonkey.com/wiki/index.php/Mai
check it out. it's cool.
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...
Before you throwing in the towel, check out the following website:
/.'ers!!
s p
http://zd1211.ath.cx/
(It used to be hosted at http://zd1211.sourceforge.net/ before moving to this new site.)
This project was started a while back to support the ZyDAS ZD1211 chipset in Linux. As it states on the site, the code was originally donated by ZyDAS. Sometime last year, I managed to contact their tech support and request another kind gesture to the open source community. A few emails later, they released an update to their original code. If I'm not mistaken, the version at the project's website has incorporated the improvements made in the company's updated code. The ZD1211 project also has a list of USB adapters that carry the ZD1211 chipset.
After checking out the project's website, check out the vendor's page as they have been keeping up with their pledge of helping out the open source community by releasing updated drivers. As a bonus, they have also released an updated **WPA Supplicant**. Enjoy fellow
ZyDAS' ZD1211 download page:
http://www.zydas.com.tw/downloads/download-1211.a
Disclaimer: I am in no way affiliated with ZyDAS. I just believe it is commendable that a company responded to a request to support the open source community and is actively doing so by publishing updated drivers.
Good luck to us all!
Try to get a LevelOne WPC-0300.
Atheros chip, 54mbit, wep64, wep128, wpa (with wpa_supplicant), no need of ndiswrapper or similar bullshit, worked right out of the box on my suse 9.2, sells for around 30 euro over here in germany.
Broadcom is one of the only vendors that doesn't provide a mechanism for native Linux drivers.
;)
Personally, I've never been happy with Broadcom's chips, and even less happy that they refuse to support the Open Source community even with a closed-source or partially closed-source driver. Even Atheros is supporting us with MADWifi and their closed-source HAL... Broadcom could do something similar.
Most of the projects either have support from chip vendors (Intel, Atheros, Agere) or there has been some reverse engineering done (TI).
TI ACX1xx chips: http://acx100.sourceforge.net
Intel Centrino chips: http://ipw2100.sf.net and http://ipw2200.sf.net
Atheros-based chips: http://madwifi.org
I think the wrapper stuff is interesting for the geek factor, but it makes me shudder when people (who don't really know what they are doing) try to use it as an end all be all solution for their wireless needs in Linux, but I'm happy for those who have actually been able to make this solution work for them.
My advice is to shop around very careful, and choose a card that does what you need it to... don't just go with the cheapest thing you can find. A lot of OEM cards have the same chipsets... you can still find some decent stuff for cheap, but it's quite likely you'll run into something that doesn't have good Linux support.
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.
The only way I found to get a desktop to access any type of wireless device, is by using a wireless bridge. These are a wireless client on one side, RJ45 wired network on the other and cost about the same as a wireless adapter. You then just plug a patch lead into it and the linux box will never know it is going wireless. Mind you, it's a bulky solution for a laptop...
Radio on your iPod
Jeff Garzik(kernel developer) has a very enlightening LKML post/rant about why wireless in the linux kernel is not yet quite up to par:
6
http://article.gmane.org/gmane.linux.network/3175
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.
NVidia wrote this script that checks their ftp site for pre-compiled modules for kernel versions of all the major distros and if it doesn't find yours it recompiles the wrapper around the binary driver on-the-fly (meaning you need kernel source/headers installed and properly configured and even then it doesn't always work). On debian I even have to hand edit a header to add the arch of my platform (-k7) to the version string, because that's what they've done for the pre-compiled kernel, but it is not in the (arch independant) source... Now I figured this out and fixed it, but many other users wouldn't. And why does every patch have to be coded in the kernel version:
e.g. 2.4.21-32.0.1.nfswan2 (RHEL 3) instead of just 2.4.21 ??
Fortunately some workarounds can be found: as pointed out elsewhere, if you use a common distro you can find apt/yum repositories with pre-compiled modules for the pre-compiled kernel versions (I use this now for NVidia). It does mean that you're usually a couple of versions behind, but I guess most people can live with that (I can). Still, it would be a lot easier (for users and vendors) if the modules were numbered by API/major kernel version, rather than kernel/patch/arch/phase of the moon version...
Jeff Garzik posted on LKML on January the 5th a lengthy article about the state of linux Wireless. See here.
John W. Linville claimed the responsibility for Wireless support in the kernel. The archive of the LKML thread is available here.
Hopefully is this going to improve things...
Violence is the last refuge of the incompetent - Salvor Hardin
hi, Have you tried ndiswrapper yet? This is an open source wrapper. I've used it ith my Broadcom wlan-card, but this wasn't a USB card. I think the general idea of installing a driver should be the same for your USB-card. If you want you can take a look at my "zv6251EA" howto 's on http://members.home.nl/ruudbeukema/techniek/linux/ . It includes setting up the wlan card using ndiswrapper.
Good luck!
Snicker... I notice no one has stepped up and given props to Intel for helping to get the Centrino stuff to work well with linux....
Well it does.
You may decide you want to hate their chips, but they do try guys...
It's a Ralink chipset card. I'm using it at right this second and it's been absolutely great including WPA encryption. Cheap card, runs at 54mbps here.
Deleted
YOU DON'T DEVELOP DRIVERS FOR LINUX.
What you do is release hardware specs, and the kernel devs develop drivers.
Yes, you can release drivers, and try to keep them synced up the kernel, just like instead of driving a car, you can just hire a bunch of people to push it down the road while you steer.
Or you can hand specs and possible some source to the devs, and they'll take over your driver, make it work, and keep it up to date.
There are three reasons to keep drivers outside the kernel: They change faster than the kernel, like the wlan drivers used to (And do not anymore. They no longer belong outside the kernel, sorry.), they contain trade secrets, or they contain licensed software.
However, trade secrets in software is just damn stupid in the first place. If you give out the software, your competitors will just, duh, take them apart to find out your secrets, and this is, incidentally, completely legal.
In the real world, these 'trade secrets' are usually 'All our hardware is basically the same, and we enable certain features in the driver based on the ID returned by the card.'. They quite rightly suspect if they turned those drivers over to the kernel devs, the devs would just turn on everything.
And the licensed software is just a red herring. If you can't release any source, you should still release the specs.
If corporations are people, aren't stockholders guilty of slavery?