State of WLAN Support on Linux? 608
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?"
ndiswrapper (Score:5, Insightful)
Re:ndiswrapper (Score:4, Informative)
Re:ndiswrapper (Score:5, Informative)
I'm running ndiswrapper under Fedora Core 4 (x86_64) on a HP Pavillion laptop with a built-in Broadcomm wireless NIC. Works great.
Re:ndiswrapper (Score:2, Informative)
Re:ndiswrapper (Score:4, Interesting)
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.
the blame game (Score:3, Insightful)
Yes, we all know that blaming the establishment is very co
Comment removed (Score:5, Insightful)
Re:the blame game (Score:3, Insightful)
In all, EVEN WINDOWS, if you start with supported hardware, the install will do most everything else. You will find both set up and willing to work. -Even windows can and usualy will give you problems if you don't use supported hardware.
Re:the blame game (Score:4, Informative)
Re:the blame game (Score:4, Informative)
Re:the blame game (Score:3, Insightful)
No one thinks users want to have to hunt for wifi support. No one thinks that users want to configure devices. The issues have _nothing_ to do with what linux developers think users want and has everything to do with developer time and vendor support.
I am sure _that_ would be the
Re:the blame game (Score:3, Informative)
Re:the blame game (Score:3)
A Modest Proposal (Score:5, Insightful)
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.
Re:A Modest Proposal (Score:3, Interesting)
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 ar
Re:the blame game (Score:3, Funny)
Where is our Hardware Compatability List website? (Score:5, Insightful)
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!
Re:Where is our Hardware Compatability List websit (Score:3, Informative)
Soundcard support is pretty decent, until you realize the OS often implicitly locks-out multiple apps from outputting audio.
Applications using alsa d
Re:Where is our Hardware Compatability List websit (Score:4, Insightful)
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...
Re:Where is our Hardware Compatability List websit (Score:3, Insightful)
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
Absolutely laughable! (Score:2)
It's nice for hardware manufacturers to provide drivers, but why should they chase a moving target?
And Windows ISN'T???
Re:Absolutely laughable! (Score:3, Insightful)
Re:Absolutely laughable! (Score:5, Informative)
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.
Re:Absolutely laughable! (Score:4, Informative)
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.
Re:Absolutely laughable! (Score:3, Insightful)
no clue! (Score:5, Informative)
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 [linuxfromscratch.org] 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
Re:no clue! (Score:3, Insightful)
True, however some distros do put on patches that can mess things up. Also it would be nice to see some companies actually package their drivers for new users, and that does need to be done individually for each distro.
Re:no clue! (Score:3, Insightful)
Metamods: the marking of the parent as Flamebait was Unfair. Please mark appropriately.
Re:no clue! (Score:4, Interesting)
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
Re:no clue! (Score:4, Interesting)
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?
Re:Absolutely laughable! (Score:3, Insightful)
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 toget
Re:Absolutely laughable! (Score:3, Informative)
Re:Absolutely laughable! (Score:5, Insightful)
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.
Re:Absolutely laughable! (Score:4, Insightful)
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.
Re:Absolutely laughable! (Score:3, Insightful)
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
Re:Absolutely laughable! (Score:3, Insightful)
Much better to just not make the promise.
Re:ndiswrapper (Score:3, Funny)
Oh, my aching sides.
Try ndiswrapper (Score:5, Insightful)
What about ndiswrapper [sourceforge.net]? 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....
Re:Try ndiswrapper (Score:3, Insightful)
Or in other words, whether you realize it or not (I suspect and hope you do) blame the other Linux users. People buying whatever and expecting support is the root problem. If people only bought hardware with good linux support, more hardware would be well-supported.
Re:Try ndiswrapper (Score:2)
Or in other words, whether you realize it or not (I suspect and hope you do) blame the other Linux users. People buying whatever and expecting support is the root problem. If people only bought hardware with good linux support, more hardware would be well-supported.
BRAVO!
Most consumers fail to realize that their wallets are the most powerful voting terminals they have (yep! more potent than electronic voting machines that produce 3000 votes out of thin air). Your wallet is your weapon in capitalism. I
Re:Try ndiswrapper (Score:3, Insightful)
What's the point of having a scale of 1-10 if most reviewers assign a score of "10" for such cruddy products?
Yes, ndis drivers are non-native. But they are not cruddy products.
Contrary to popular belief from lateday users, ndis are not windows' drivers.
We have been using them for a long time, on systems randing from DOS, OS/2 and Netware. The idea for NDIS drivers is (was?) to make platform independant drivers. So having NDIS support on Linux
Re:Try ndiswrapper (Score:3, Insightful)
Re:Try ndiswrapper (Score:3, Insightful)
The ndiswrapper guys go on fine tuning their software, the device manufacturers can go make a single binary, everybody's happy.
What am I missing?
Re:Try ndiswrapper (Score:5, Insightful)
Re:Try ndiswrapper (Score:3, Informative)
Re:Try ndiswrapper (Score:3, Insightful)
Re:Try ndiswrapper (Score:2, Interesting)
--
"I think; therefore, I am Libertarian"
Re:Try ndiswrapper (Score:3, Informative)
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 som
Re:Try ndiswrapper (Score:3, Interesting)
It's possible to write the firmware in such a way as to separate legal requirements from the work a d
Re:Try ndiswrapper (Score:3, Informative)
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
Me too (Score:2)
rt2x00 (Score:5, Informative)
Re:rt2x00 (Score:5, Informative)
For what it's worth, Ubuntu supports this chip out of the box with their restricted modules package, and I didn't have to do any CLI work to get the chip working under Breezy on my latest laptop, unlike a similar model that I bought last year which I spent a fair amount of time researching the chip and compiling the driver under Warty. Under Breezy, it only required filling in the necessary info in the standard network configuration dialog.
Re:rt2x00 (Score:2)
Have you tried ndiswrapper? (Score:2)
Only? (Score:2)
The problem, I think, is always the same... (Score:5, Insightful)
Re:The problem, I think, is always the same... (Score:2)
I'm not actually sure wtf submitter was thinking.. hopefully next time they will research purchases for their Linux boxes a bit more carefully before plonking down their cash. Wishful thinking won't make drivers magically appeal. If the traditionally less spendthrift Mac co
Re:The problem, I think, is always the same... (Score:5, Informative)
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.
Re:The problem, I think, is always the same... (Score:2)
It should be noted that you should do some research and find this kind of shit out ahead of time, and choose who to buy from and what to buy accordingly.
Incidentally, this
Suse 10 (Score:2)
Found my highly generic Atmel chip set WLAN card (USB), configured instantly, on-line in less than 3 minutes from inserting the card.
Kubuntu and Knoppix both failed totally.
Steve
Re:Suse 10 (Score:5, Informative)
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.
Re:Suse 10 (Score:2, Informative)
Linux and wireless (Score:5, Informative)
Apple Hardware (Score:3, Interesting)
do your homework before your splurge your money? (Score:3, Insightful)
I think that its more complicated (Score:2)
Re:I think that its more complicated (Score:2)
Re:I think that its more complicated (Score:3, Interesting)
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 most
802.11g under linux is somewhat messy. (Score:5, Interesting)
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.
Madwifi (Score:5, Informative)
Re:Madwifi (Score:2)
I've been using a D-Link DWL-G650 (Atheros chipset) with the Madwifi drivers quite successfully for a while now. Even have WPAv2 working. This is using Gentoo and its awesome wrapper config scripts for network/wireless setup.
Prior to this card, I had a Netgear WG511 which worked using the Prism54 drivers. But then it died and I got an RMA replacement...the replacement I received (same hardware revision, mind you) did not work because of something that they offloaded from the h
Ralink (Score:3, Insightful)
http://ralink.rapla.net/ [rapla.net]
Wireless drivers (Score:5, Informative)
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.
You have the choice of Atheros, Ralink, Intel, (Score:5, Informative)
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.
Linux wireless card compatibility list (Score:5, Informative)
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.
Kerneltrap had an informative article on this (Score:2)
another banner year has passed, with Linux once again proving its superiority in the area of crappy wireless (WiFi) support. Linux oldsters love the current state of wireless, because it hearkens back to the heady days of Yuri Gagarin, Sputnik and Linux kernel 0.99, when getting hardware to work under Linux required either engineering knowledge or luck (
blame it on everyone except Linux... (Score:2, Interesting)
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 199
This is why we need a kernel api and abi (Score:3, Informative)
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.
The state is dismal (Score:2)
If you haven't got your heart set on Linux... (Score:3, Informative)
* And excellent documentation, a brilliant firewall, a wonderfully clean code base, superb ports system and super sweet line of T-Shirts! =)
Get a Centrino Laptop (Score:2)
Support is very [sf.net] good [sf.net].
Use a bridge (Score:2)
Belkin low-end wireless routers can bridge to each other. Motorola makes a decent bridge at a reasona
KernelTrap (Score:2)
acx111 works well (Score:3, Insightful)
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?
Re:acx111 works well (Score:3, Insightful)
The driver needs to be able to load a firmware image when the module is loaded. It sounds a bit complicated perhaps, but it should just be a matter of putting a file in the right directory and it will all be handled automatically from there onwards. Information about that a
There's this nifty thing called Google... (Score:5, Interesting)
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...)
Re:There's this nifty thing called Google... (Score:3)
As for FCC Certified techs doing installations, I know of no such requirement. Now, installations must meet FCC regulations reg
Re:There's this nifty thing called Google... (Score:3, Informative)
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.
Linux Tip #1.6 (Score:2)
Research before you buy.
Check the Hardware Compatibility List next time (Score:3, Informative)
Ndiswrapper works great on belkin 802.11g card (Score:3, Informative)
Kernel developers looking for dramatic change here (Score:3, Informative)
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 [osdl.org])
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!!!
2 Major problems (Score:3, Insightful)
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.
No, DON'T use ndiswrapper (Score:5, Interesting)
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 [netgear.com]. 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 [madwifi.org] drivers. Configure ath0 for DHCP, sit within range of an access point, and you're good to go.
The madwifi drivers work with Atheros [atheros.com] 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 [madwifi.org] 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.
Re:No, DON'T use ndiswrapper (Score:3, Informative)
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.
$state = confusing * 10; (Score:3, Informative)
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.
Edimax EW-7108PCg native driver including WPA (Score:3, Interesting)
Re:You should see wifi support for OSX (Score:4, Funny)
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?
Re:Manufacturers need to publish specs (Score:3, Insightful)
Maybe then the manufacturers will begin to listen.