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?"
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.
The chipmakers...the dogwalkers whomever...but dont ask companies
like Novell and Redhat to spend a little bit of money to make wireless
networking actually work on linux. Dont ask the linux community to stop
putting in new whizbang features and get the existing features to actually
work as they are supposed to and dont you DARE question why wireless support
isnt part of the kernel instead of some extra add-on that gets ignored.
The 802.11 standard has been around since 1997, the 802.11a and b standards since 1999.
Even 802.11g is mainstream now and I still cant take my laptop to a hotspot turn it on
and it just work...
One of the comical things is Broadcom has Linux drivers that they use internally and on their AP's. From what I understand, BC uses the same Chipset on their AP's and adapters. Many of those AP's run on Linux (I.E. Linksys WRT54G), thus they have the code. I am just curious whether or not BC is violating GPL by not supplying the code, since they have done the work.
--
"I think; therefore, I am Libertarian"
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
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.
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
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.
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.
A company releasing a radio transmitter for public consumption really does have to certify that the end-user cannot control the device in such a way as to cause it to violate the FCC regulations. It could be difficult for them to do this if they're simultaneously helping external developers get low-level control. I've not heard of anyone getting called on this, but it's quite possible that it could happen.
It's possible to write the firmware in such a way as to separate legal requirements from the work a driver needs to do, but this is not easy. Also, since the same hardware can often support multiple regulatory areas with only a changed driver, there is incentive to keep the low-level hardware/firmware as flexible as possible.
For an end user, it is, in fact, illegal to modify radio hardware to operate in contravention of FCC rules. Realistically, you're not likely to get nailed because you're not likely to cause harm (so no one will notice) and it takes substantial resources to track you down. I'm not sure what the status of a project distributing code would be, though. I don't imagine it would be encouraged, but would probably have to get to be pretty big before it would draw enough attention to be in danger.
Big problem with this is that most of the wireless features we know and enjoy are done in the software drivers, for broadcom chipset cards at least.
The broadcom drivers are not just an API for windows to use to talk to the network - they include encryption, all the WEP/etc stuff, AND network scanning, and everything. The card is basically just the antenna for the drivers.
That's the reason they won't opensource it - because then people will realise that the cards are low quality for the price.
Speaking as someone who used a broadcom chipset card on ubuntu for quite some time, and could never get it to work quite right with ndiswrapper.
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?
First, realize that I have been using Linux _forever_... I think somewhere in the 0.8 kernel range. (I was absolutely in before 1.0, because I sent Linus a congratulatory message when he released it, asking if he had a favorite charity. He never answered me, which cost that entity, if it exists, $50.) So calling me an anti-Linux zealot is completely stupid. I'm upset about this new bullshit development model in 2.6, but I have been a Linux fan for more than ten years. I'm not deeply into the code, but I have been administering Linux machines for a LONG time.
When you say I run and use Linux and Windows on a daily basis... something you have obviously never done., in other words, you look like a total idiot.
You say: 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.
Windows NT 3.1 shipped in 1993. In 1996, NT 4.0 moved display and print drivers into kernelspace. That didn't impact non-print and display drivers, and I don't think it was much of an change even for those. It certainly was no trouble getting my drivers updated. (I started with NT at 3.5.) As far as I know, Win2k was the first major driver shift in the NT line. It shipped in 2000.
So in other words, you have 3 years to the first change, 4 years to the second, and 6 years and counting to the third. I'd call that pretty goddamn slow... downright glacial. Win9x was in more flux, but with the advent of Win2k, SIX YEARS AGO, all that flux stopped. The flux from pre-2000 is totally unimportant to anyone developing software today, anyway.
So OF COURSE WINDOWS MOVES SLOWER. Unless, of course, you're arguing that the driver model for Linux hasn't changed in the last six years?
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.
Sure, but someone had to do the porting. Windows drivers that were written in 2000, to my best knowledge, will still work just fine, although you'll have to click on "ok to run unsigned code". And if your driver isn't in the kernel tree, it requires constant attention. The kernel API is changing constantly, as they deprecate old interfaces and shut down calls for 'non-GPL' drivers.
If I had written a driver for Linux, in other words, I would have to be tracking kernel changes very, very carefully. With Windows, I'd just now have to be picking it back up again after six years.
[... a bucketload of absolute garbage about OS versus kernels snipped]
I'm not talking about the OS. I'm talking about the kernel. Linux no longer has a robust center. Once upon a time, there was a stable kernel tree that was really stable. (see: 2.4.X). A driver creator could write a module just once. If it worked for that center tree, that was all they had to do. Any other distro that picked it up and subsequently broke it... well, that was their fault. If a module worked in the official stable tree but didn't work in Redhat's version of the kernel, that was clearly Redhat's fault.
With the fact that Linux no longer works reliably without vendor-supplied patches, now there's no stable center to test against. Instead, a driver creator has to test it individually against each different version of the kernel. And in some cases, it's very messy, as one of the posters pointed out: Redhat 2.6.9 claims to be 2.6.9, but has the interface layout for 2.6.10. This breaks stuff.
So now, if a module breaks with RedHat, it's the module writer's fault, not RedHat's. Since Linus has announced that his tree isn't stable enough for general usage, then just writing to that tree isn't enough anymore. That increases the load for driver writers enormously.
Instead of one
I'm not deeply into the code, but I have been administering Linux machines for a LONG time.
So being a slightly more educated end user somehow makes you qualified to speak on code? You run programs, not write them, you haven't the first clue about anything you speak. This is akin to someone who has driven for a few years but never popped the hood of their car trying to explain to a mechanic that they don't know what they're talking about.
Windows NT 3.1 shipped in 1993. In 1996, NT 4.0 moved display and print drivers into kernelspace. That didn't impact non-print and display drivers,
Have you even read that sentence? They moved two major subsystems into the kernel, but no worries, it doesn't affect you if you are not part of those two subsystems! In the linux 2.0 days, there was ipfwadm, 2.2 ipchains, and 2.4 till now, iptables/netfilter, those are significant changes! But it didn't impact non-firewall drivers!
Sure, but someone had to do the porting. Windows drivers that were written in 2000, to my best knowledge, will still work just fine, although you'll have to click on "ok to run unsigned code"
Some will, some won't its a crapshoot. Hell even a lot of userspace programs break under 2003. Things changed from 9x to NT, and from NT to 2000, 2000 to XP changed again, but often its pretty much the same. XP to 2003 things changed a lot again, and from the little I've seen from Vista, a lot has changed again. This is somewhat like the changed from 1.x to 2.x, to 2.2, to 2.4, and 2.6, and so on.
I have a kernel driver that I have maintained since the 2.0 days, significant changes have happened to the linux network layer since that time, in between 2.2 and 2.4, the whole thing was damn near rewritten eliminating bottoms halves and so on. Each minor version bump I have indeed had to make a few changes here and there, most of the time its to change the logic slightly, or the name of a structure, and even in 2.6 how the module was compiled, but they have always been fairly trivial changes. I also maintain a driver for windows that operates on physical memory, this has needed far more changes over the years (since win2k) than my network module in Linux. The point being that even with major changes under the hood I have always been able to hook in my parts with minimal trouble under Linux, which hasn't been the case under Windows. *And this comes from someone who actively maintains code under both, a person who makes use of the APIs and their changes, not someone who pushes enter and while he waits for the code other people have written to do their thing thinks up half-assed arguments based on shit he read about somewhere but doesn't have the first clue what he is talking about*
Instead of one Linux kernel (which is what I was ALWAYS talking about, despite your bullshit about confusing it with userspace), we now have ONE PER DISTRO. There's not one Linux kernel, there are at least four or five. That's a lot of testing and maintenance to have to do. Testing and maintenance costs money.
I suppose you're the type of guy that thinks 'gee recompile the kernel?!', seriously, All of my linux boxes are using the same kernel, across 4 distro's and 3 architectures.
Tell me... have you ever run a network of a hundred or so Linux servers? I mean all of it, all by yourself... from the firewalling to the routing to the DNS servers to the OS maintenance. All of it. Everything. Production network.
No, and any company that has an entire production network run by one guy is as stupid as the one guy running it, it doesn't matter if we are talking about 20 boxes or 20,000, and yes I've admined both sizes. Once again though, I have to ask, as a professional enter-key-presser (admin), what makes you think you have the first clue about anything related to APIs or so on?
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.
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.)
I've had similar problems with "new improved versions". The reason why this is worse for wireless hardware seems to be:
1. The hardware seems to be very short-lived, with each "version" only being around for a short time. By the time the driver has been written the hardware is off the shelves.
2. New "versions" of the hardware aren't progressive improvements, they are complete re-designs of the hardware using completely incompatable components and designs.
3. Different "versions" are marketted under the same name, model number and in some cases even the same FCC ID so there is literally no way to tell it's the right version without actually looking at the hardware itself (something you can't do when mail ordering and I'm guessing many shops would take issue with you opening up the boxes to look at the hardware).
Now, I'm not sure why (1) should be especially true for 802.11 kit, but it does seem to be the case - given the engineering effort involved in creating a brand new chipset it seems strange that they only keep them around for very short periods.
As for (3), I can understand them using the same _name_ but the only people who look at model numbers are the people who actually need to know what hardware it is so it seems crazy that they don't change the model number. I'm not sure how they get away with not changing the FCC ID - surely a completely re-engineered piece of hardware needs to be re-approved?
http://blog.nexusuk.org
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...
They don't, because the windows drivers don't either.
So in that respect, linux wireless support is better than windows, we can use all the windows drivers *and* do rfmonitor mode on certain cards, not to mention use wireless cards on non x86 architectures.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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?
They work fine for the actual communication, but can't do any sort of scanning or sniffing.
I don't know who's in charge of the spec, or how extendable it is, but that would be a really nice addition.
If corporations are people, aren't stockholders guilty of slavery?