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?"
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/
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.
Try changing your card to monitor mode a few times. With the latest releases, the drivers may hang the system and block all keyboard input (mouse still seems to work), requiring a hard reboot. Oh yeah, and AirSnort doesn't seem to be able to identify weak IV packets with the current drivers.
mnemonic_
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).
I'm using a Belkin 802.11G adapter with ndiswrapper. Works like a charm for me - just be sure and have the ndiswrapper sources around to make for when you do kernel upgrades...
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.
hopefully next time they will research purchases for their Linux boxes a bit more carefully before plonking down their cash.
It should be noted that you generally have no way of knowing the internal chipset in a network adapter from anything printed on the outside of the box. Manufacturers often sell two or more entirely different devices under exactly the same name, in exactly the same packaging, with nothing to distinguish them except serial numbers.
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! =)
works beautifully for me. Linksys wireless G and B PCMCIA cards. This is likely why no one is reverse-engineering them anymore, no point.
Every OS has them available freely, it would be a good idea to doublecheck before making hardware purchases for ANY os (Windows excluded).
For great wireless support try OpenBSD. They support an amazing number of wireless cards, the man pages list which exact models are supported, and they are treated just like any other network interface so you don't need to use weird utilities to set them up. I'll never go back.
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).
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!!!
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.
To be clear, FCC regulations do not allow one to break copyright law. If one is extending GPL'd code in a way that FCC regulations do not allow one to distribute, the fact that one is not allowed to distribute that code legally prevents one from distributing binaries compiled from that code.
IANAL, but my impression is that it's mere speculation that open source software that controls radio transmission hardware is somehow prohibited by FCC regulations. There are open source projects that do give one the ability to control radio transmission hardware, and I haven't heard of any of them being shut down or restricted in any way by the FCC. If anybody has any hard evidence on this, I'm interested in seeing it.
I dual boot my notebook with both DimWoes XP Professional and Kubuntu 64-bit Edition. Under Kubuntu, I use the ndiswrapper package for wlan support and the install was amazingly straight forward, didn't require ANY compiling or reconfiguring of the kernel, only finding the 64-bit Windows driver, which I have if you need it. Added benefit: the wireless light on my Compaq Presario R3000 notebook blinks under ndiswrapper when it's being accessed. Under DimWoes, it just stays on all the time. I like the behavior under ndiswrapper better. It lets you know when data is actually being transmitted/received. Anyway, here's the instructions that I followed that got me up and running in about 1/2 hour: http://ubuntuforums.org/showthread.php?t=31926 Hope that helps. Best Regards, Kalecomm
Some drivers are already implemented in userspace - see libusb.
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.
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.
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
Well, to be fair, this isn't always the case. Ubuntu for instance worked perfectly on the first try with my Centrino based laptop.
Throw the bums out!
Its far more expensive to put TX power limits in sillicon (if it can be done at all) than to put TX power limits in software.
Also, different countries have different rules. Making one piece of hardware and adding different software or drivers for each reulatory area is much cheaper than multiple masks/fabs.
I must have lucked out with my WLAN cards. I bought a laptop in 2004 with an Atheros Super G chipset in it and a Belkin USB dongle with a Ralink chipset. I don't need NDISwrapper crap at all. See if you can find a driver before going straight to ndiswrapper/DriverLoader.
The way it looks now, here's my advice:
Chipsets to go with:
- Atheros b/g/a chipsets
- Ralink chipsets
- Intel chipsets (found on Centrino laptops, for example)
Those are the most often recommended for Linux, and all of them have stable NATIVE drivers with open-source (except for the FCC-required parts--the FCC demands that parts of the Atheros driver be proprietary).
AVOID BROADCOM AND TI. Those chipsets only work with ndiswrapper/driverloader.
Note that this has nothing to do with the brand name or model number of the card itself. I'm referring to the chips themselves.
Microsoft-free since March 28, 2004
Madwifi drivers aren't fully open. They have a binary only 'HAL' that does the real work internally.
If atheros disappear overnight, the next time the kernel undergoes a significant change, you've lost support for your card.
Same goes if you want to run it on some sort of exotic architecture.
Malike Bamiyi wanted my assistance.
I'm running ndiswrapper under Fedora Core 4 (x86_64) on a HP Pavillion laptop with a built-in Broadcomm wireless NIC. Works great.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Add the venerable Orinoco 802.11b to that list also. Works like a champ on my laptop.
Just "gittin-r-done," day after day.
To push your point a little more. I bought a 802.11g netgear card. I put it in. I booted Ubuntu from the LiveCD to check the support. It automatically detected the card and connected me to the nearest open WAP. Far far more painless than the Windows equivalent.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
A post is informative if it gives you information, something that you could look up somewhere if you weren't posting to Slashdot.
A post is insightful if its author exhibited a certain turn of mind, where you are left asking "Why didn't I think of that?".
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.
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!
Yes, let me be clear. I was not meaning to imply that FCC regulations somehow free developers from their responsibilities under the GPL. Just that in practice they tend to prevent full compliance with the GPL. I remember reading something Linus wrote about binary-only drivers and how something like a HAL he could turn a blind eye to (since they're often developed for multiple systems and so not a derivative work in a real sense) but he didn't like the idea of a full binary-only driver developed specifically for Linux.
Still, if you take any distro that ships with one of these binary or half-binary drivers (take, for instance, Knoppix which ships madwifi), if you note the dmesg it warns you that adding the HAL taints the kernel, which means in theory they shouldn't distribute it any more. But, it's a blind eye that most of us seem willing to turn.
All's true that is mistrusted
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.
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
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!
Technically it won't break Ndiswrapper any more than it is already broken. Windows drivers already expect stacks to be at least 12k, so reducing the stack size from the present 8k to 4k will merely expose the innate shortcomings of Ndiswrapper and similar solutions.
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...
What makes research extra hard is that cards sold with similar model names might contain completely different chips inside, depending on the revision. And often the differences between different revisions are rather scarcely documented. Such as that list you showed, it tells nothing about the different variants of 3com Officeconnect 11g's, some of which work fine without ndiswrapper, and some of which don't.
The problem for sound cards, and the reason for not mixing everything at dev/dsp is this:
A DAC can only operate at one samplerate/bit depth at a time.
If one application opens the sound card at 44.1K, then another opens it at 8K while the first is still playing, what do you do?
The simple answer would be to src to 8K up to 44.1K and mix the streams.
But what happens if the first app opened at 8K, and the second at 44.1K?
You now hear your 44.1k audio SRC'd to a glorious 8K sample rate.
Now imagine the first 8K app stops, the SRC'd 44.1K carries on, and another 44.1K stream is added. Now you get both 44.1K streams SRC'd to 8K! Or you could switch sample rates, and get a big glitch as the SRC is removed and the DACs reclocked.
It's unpredictable and broken behaviour. Not to mention the fact that random resampling is totally unacceptable in a proffesional audio context.
Some cards like the EMU10k1 based ones have a fixed sample rate, internal SRC and allow many streams. This works OK if you don't mind consumer quality audio and no accurate digital transfer. And guess what! The EMU10k1 cards work fine with many simultanious streams/rates under ALSA.
Now... more and more cheap cards nowadays are *fixed* 48K and only support a single stream.
The ways around this are to SRC virtually everything and mix the streams before they get to the sound card. This is not a job for the ALSA driver as it cannot know what the 'right thing' to do is for every user, especially those who want to avoid the above problems. So the user can pick a sound server if they like, but a least they still have the chance not to use one and have predictable operation at 48K if they desire.
ALSA also provides it's own dmix plugin which allows many streams and only moderately broken SRC behaviour, so you can avoid an external sound server as well.
I guess it's a stand off between those who want 'correct' behaviour, like me, and those who want it to 'just work dammit' and don't really care about the quality.