Slashdot Mirror
NDIS Wrapper For Wireless LAN Cards Under GPL
An anonymous reader writes " Shortly after Linuxant has released their commercial
DriverLoader, Pontus Fuchs
has made an NDIS wrapper available under the GPL.
Since some vendors refuse to release specifications or even a binary Linux-driver for
their Wireless LAN cards he has decided to
solve it himself by making a kernel module that can load Microsoft-Windows NDIS drivers.
ndiswrapper
has been tested with some BroadCom miniPCI cards and it seems to work on some laptops . With some more work it
should be possible to support more cards. Hopefully this will be the case for
the many owners of Linux laptops based on Intel's Centrino technology.
Please contact Pontus if you are interested in helping out!"
How does he expect people to try out his code without any screen shots????
main(i){(10-putchar(((25208>>3*(i+=3))&7)+(i ?i-4?100:65:10)))?main(i-4):i;}
As long as the NDIS wrappers support all the capabilities of the cards, this is great news!
compared to a native driver, but certainly helpful in reverse engineering the windows drivers.
***Quis custodiet ipsos custodes***
Would someone care to point out which cards have native Linux drivers available? Once we have this list I think we should go out of our way to buy from vendors with Linux drivers.
UNIX/Linux Consulting
This is kind of a double edged sword. Now that you can use NDIS drivers under Linux, it will be that much harder to convince these companies that providing a native Linux driver would be good for their business...
If you are in the market for one of these cards, buy from a company that supports your OS of choice...
The wrapper should send an e-mail to the hardware vendor every time it loads. As more people use the wrapper, they get more and more e-mail. Perhaps they would rather write proper Linux drivers than get more e-mail. ;-)
Here's a nice list at HP of cards that work.
For quite a while now, I've considered what sorts of problems would be inherent in cross platform drivers. Usually, the problem seems to come back to a difference in the way kernels manage their drivers and differences in the way that I/O is done between OSes. Perhaps a "Driver Adapter" could be built that would allow drivers written for it to run on any OS? The basic concept is that the adapter itself would be a driver for the OS, then the "Cross Platform Drivers" would deal directly with the adapter.
Anyone have any thoughts on why this would or wouldn't work?
Javascript + Nintendo DSi = DSiCade
Good news : I can get that %^*@$# network card going now.
:
Bad news : Nobody will bother to write Linux drivers soon enough, they'll all say "why bother, we'll just make a Windows driver and tell people to use the wrapper.
Net results
- This makes card vendors inclined to think only the Windows platform is truly important
- This allows Microsoft to have the option of one day changing, subtly messing up or adding undocumented calls to their API, slowly leaving Linux people in the cold as all card vendors transition.
- I would think native drivers are faster / more efficient / more full featured than drivers running under emulation. That might not be the case though, but more often than not, running alien binaries in any OS isn't known to be as fast as the real McCoy.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
This wrapper sounds a bit like the UDI Project creates a universally consistent driver DDI across all platforms. All drivers are source code compatible for all platforms with an environment. Drivers are binary compatible between platforms with a common C ABI.
Unfortunately Caldera was the main weight behind this, back when they actually did something silly like write code to make money instead of sue. They fell on hard times and essentially pulled support, and it's been dead in the water since.
How does the licensing work with this? If it's GPL, isn't it being linked (albeit in a kind of weird runtime way) with proprietary code? It seems a nice idea to write code in order to export the features of proprietary code into open software, but how do you distinguish it from programs that do the opposite?
Is this implemented in kernel space still? Is it possible to implement a driver wrapper like this in Ring 3, or at least in Ring 1 or 2, thus reducing the effects of a driver crash, instead of Ring 0?
Looks like more and more Linux is simply emulating Windows. But if you run Windows drivers and Windows programs via appropriate emulation layers, why not simply run Windows?
MSDOS: 20+ years without remote hole in the default install
The only bad thing I experienced when testing this NdisWrapper was that I needed Linux 2.6.0-test8 or higher.
I don't want to run a beta version of Linux, so is there any good reason for this?
Note to self: get smarter troll to guard door.
There are people here claiming that we'll never see Linux drivers because of this.
The main reason this is required, however, is because the latest chipsets for wireless give too much control to the software. That means the user can theoretically control transmit levels and frequencies, and make their transmission interfere with other people's communication.
Since the transmit power levels and frequencies are all set differently in different parts of the world, the closed-source software is needed to restrict people's control over the hardware.
And that is a real bummer. It is hard to support closed-source Linux drivers - people don't particularly like them, there are thousands of different kernels out there (each distribution has about fifty or so current at any one time, not to mention all the patches you can download from kernel.org).
As a result, this doesn't surprise me at all. I think it's probably the only way modern WiFi will be supported under Linux. That doesn't translate to the end of the world, however, since the regulatory situation is quite different for almost everything else in the computer.
A stable Linux driver API/ABI. This is getting ridiculous. Windows drivers compiled for a 5 year-old version still work on the current version (maybe a slight exageration), while a driver compiled for 2.4.21 won't work with 2.4.22. Not only that, but even with the same version, driver compatibility depends on SMP option, highmem, ...
Opus: the Swiss army knife of audio codec
"Since the transmit power levels and frequencies are all set differently in different parts of the world, the closed-source software is needed to restrict people's control over the hardware. "
It's a matter of opinion that "restricting people's control over the hardware" is necessary or appropriate. If there is some compelling state interest, then it should be considered a defective and/or dangerous product, which ought to be dispensable only to licensed purchasers.
Treating it as a problem that the consumer owns does not solve the problem. Just because the manufacturer hasn't enabled the consumer to alter the card's programming, doesn't change the fact that the dangerous device has been distributed into the wild.
As soon as some independent party (not subject to the US law-by-agency-order), creates software to unlock these cards, the disabled-by-obscurity features will be open. If that's a problem for the state, then they should have considered it before allowing the product to be sold.
If some product can be converted to a weapon, the fact is, the weapon is in the consumer's hands whether you've told him how to convert it or not. You hold some of the responsibility for this product getting into the consumer's hands.
-fb Everything not expressly forbidden is now mandatory.
Following your argument, why don't the wireless card makers release specs then? If they're off the hook regarding using these wireless chipsets for illicit purposes, why don't they just release the specs?
Because every hardware company that releases a product believes that they either
Have a competitive advantage and need to keep it a secret.
or
Have a crap design and need to keep it a secret.
or
Have the same design as everyone else and need to keep it a secret.
I know a girl whose name is "Ashley Fuchs". Her email sig simply reads "It's pronounced fox."
Can someone tell me why this was modded down ? There is nothing trollish about that . I mention that you need to fight the hardwared makers or they wont assist at all.
If this works, then no one will bother developing an open source driver, which means there is still no hope for using Airport Extreme, which uses the Broadcom chipset, under Linux on a PowerBook. =(
1, 1, 2, 3, 5, 8, 13, 21 -- Mathematics is the Language of Nature.
Its actually quite hard to reverse engineer modern hardware. Gone are the days of a few bits to twiddle on an IO port. Now we are talking entire protocol stacks for complex protocols with varying amounts of the stack and/or compression implemented in hardware. Go read the USB or 802.11 specs sometime. This is not your grandfathers' serial port. Yes, I am experienced at writing device drivers. I reverse engineered a major USB webcam chipset for Linux, and I've written many older drivers.
Or better, contact Intel and ask them, why in spite of all the hype and marketing announcements about them supporting Linux, they have silently failed to deliver either Centrino drivers or Centrino documentation.
Frankly, I'm rather surprised that no Linux company has sued them yet, for unfair competition. Disclosing drivers and documentation to one OS maker and hiding it from the others IS unfair competition.