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!"

Comments

Not the best solution

[mocm]

compared to a native driver, but certainly helpful in reverse engineering the windows drivers.

Double edged sword

[Mr Bill]

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...

Re:Double edged sword

[nbvb]

Heh, this sounds like the OS/2 problem:

We make a better DOS than DOS, and a better Windows than Windows!

So who'd bother writing for OS/2 when I can just write for Win or DOS?

Re:Double edged sword

[Lussarn]

Except that very few companies write for Linux anyway. Of course, very few wrote for OS/2 too but linux have a much stronger community than OS/2 ever had.

We don't even want closed source binary drivers. We want the specs for the hardware.

I don't think there ever was a OS/2 problem as it is described. Noone wrote for BeOS either and BeOS didn't have ANY apps. Surely it's better to run windows apps than nothing.

Re:Double edged sword

[Minna Kirai]

This is kind of a double edged sword.

That's the same argument that comes up around Wine, or other projects that allow non-native applications to run on a platform- backward compatibility might discourage creation of true native apps.

It's a valid concern. But for the position Linux is in today, it looks like a degree of Windows compatibility will help more than it hurts.

If two systems can share binary applications and drivers, then a barrier for users to switch between those systems has been reduced. Compatibility might encourage switching in either direction- but the rule of thumb is that lowered switching costs helps minority solutions increase their popularity.

Virtually everyone uses Windows(r)... if switching to other things were easier, then more people will switch, and the number of Linux installs will increase.

If you are in the market for one of these cards, buy from a company that supports your OS of choice...

One way a company might "support" linux is by including this wrapper module with the hardware, and pointing Linux customers to instructions on how to use it. This way, hardware vendors can take a gentle slope towards native Linux support: their initial investment in software programming is minimized, but they can get accustomed to the idea that some of their customers are buying for Linux, and that the platform deserves support in the future.

Re:Double edged sword

[Minna Kirai]

That's often mentioned as an argument against a competitor's legacy systems, it's more complex than that. Linux and OS/2 are substantially different.

Back when IBM attempted to push OS/2 to the buying public, it was a $100+ product, while DOS/Windows was "free" (it seemed free from the end-user perspective, in that it came with every computer and customers couldn't reduce PC cost by declining DOS)

Today, however, Linux is a $0 product, and some buyers now have the option of bare-bones systems where Windows(r) would look like a $299 add-on.

So OS/2 was more expensive than Windows. Using it to run Windows apps was wasteful. But Linux is less expensive than Windows, so if it turns out it can run Windows stuff adequately, people will turn to Linux as the cheaper choice.

(And then, when/if Linux gets major marketshare, more new commercial programs will tend to be aimed at Linux first)

Re:Double edged sword

[PCM2]

Well, a counter-example might be Mac OS X. You could write apps for OS 9 and they would run in Classic mode. Or, you could code to the Carbon libraries and your apps should work on both OS 9 and OS X. Or, you could write your apps to the Cocoa frameworks, and they'll only work on OS X, yet they'll be "better."

Seems to me that, while the initial reaction was to code to Carbon, most brand-new applications being written (or rewritten) for OS X these days are Cocoa applications.

It's not the same thing as the OS/2 example, exactly, because Apple controls both the Carbon and Cocoa libraries and has pretty much announced the death of OS 9, so backward compatibility is not an issue. But if you consider that even established Mac OS developers have begun coding to Cocoa in spite of their past investments in Carbon/Mac OS 7-9.x development, it seems that some vendors, at least, are capable of seeing the value in doing something the "better" way, rather than just sticking to what they know.

Where hardware vendors and Linux drivers are concerned, we'll just have to wait and see. This seems like a case where everybody really should hope Linux gets "ready for the desktop" -- because a couple million laptops out there running Linux as a primary OS are going to convince the hardware manufacturers a lot more quickly than a bunch of servers will.

Kernel space?

[42forty-two42]

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?

Re:Kernel space?

[42forty-two42]

I don't see why it can't go through e.g. mapping memory and using real-time signals or reading from a device file to receive interrupts...

Next step: integrate with Windows Update

[mentin]

I can see that soon this will go to Windows Update to find new or updated NDIS drivers.

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?

Re:Licensing issues

[mrroach]

Because the GPL is only a distribution license. The user can link against whatever they want. That's why proprietary kernel modules are ok.

-Mark

The reason that this is required: Interference

[Karora]

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.

Re:one bad thing

[Anonymous Coward]

I would be far more worried about this alpha-quality ndis-trickery crashing my system than a 2.6.0-test kernel.

Re:Licensing issues

[PugMajere]

No, Linus added that *well* after he began receiving contributions from others.

There is no reason to think that Linus has total control over the licensing restrictions that the kernel is distributed under.

Anyone who tells you otherwise is wrong.

Re:The reason that this is required: Interference

[kwerle]

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.

Re:Cross Platform Drivers

[parnasus]

... every judge in the US is going to throw the book at them.

If history is any judge, that book is probably going to be made of tissue. Nothing the judges have thown at Microsoft so far has done anything to deter them.

PowerPC

[O]

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. =(

Re:We also need...

[jmv]

I'm not saying the ABI should be frozen for 5 years, but I think every it shouldn't with micro version numbers. The same driver should work for all of 2.4.x. Now, I know most drivers have source code with them, but sometimes a binary is just much simpler. I mean I can also have the source for XFree86 and OpenOffice, yet I'd rather just get the binaries.