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!"
Here's a nice list at HP of cards that work.
An NDIS driver provides functionality to make the card work. Its a standard way to operate with the card from a program if you dont know a particular card's interface. So no, NDIS does NOT support all the capacilities of the card as far as alternate forms of authentication and the little extra goodies the manufactorer puts in. But, it will get the card working with its basic functions which is better then not working at all.
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.
Even microsoft complains that many of the crashes in their OS are due to bad drivers - doesn't this just open up the linux world to potentially shoddy driver code with no recourse of fixing it? The upside of open source drivers is that we can fix the problems when (not if) they occur. There is a significant downside to supporting a company that does not release open source drivers - IMHO they better have a really good reason, and most of the reasons they typically come up with don't cut it.
cards besed on the prism chipset and the orinnoco/hermes chipset(s) work very well. Cisco aironet cards have worked pretty well for me, too. I think the big stinkers are the broadcom based ones.
Read more carefully: There is a way to build it in 2.4.x since about yesterday.
NDIS is a cross-platform network driver model, or at least it was when I worked with it ~10 years ago. An NDIS driver never calls the OS directly; everything goes through the NDIS wrapper, thus providing an abstraction layer over the actual OS.
Now, if someone will just write a similar layer for Linux that can load Windows NT filesystem drivers, then I can get read/write access to my NTFS partitions... Hmm...
Likewise, I've also been able to use the Linux-WLAN-NG drivers to make various wireless adapters work under Redhat Linux versions 7.2 and 9. The devices that I have actually used successfully are:
I noticed that the README file included in the download mentioned a "BroadCom" wireless card. I'm curious as to whether or not this is the newer Linksys PCI wireless card (WMP11) which used to work with Linux-WLAN-NG before they changed the friggin' chipset from Prism2 to Broadcom.
In case of fire, do not use elevator. Use water!
The original NDIS specification predates Windows NT, 95, et al. It was, in fact, targeted at DOS and OS/2. A little Googling [see this, this, and this] shows that it has a long (if not glorious) history. IIRC, NDIS binaries would load unmodified in Win NT and Win 95. This is pretty cool given these two OS's vastly different I/O models.
Here is a link to a page about it.
It's a neat idea, but I'm not sure how popular it is with hardware makers, and it somewhat constrains the implementation in hardware. The basic underlying princepals of the hardware would have to support the way the high level model is written, as opposed to having the software conform to the software.
It has to be a split driver model, as OS's organize themselves differently, so what would be highly efficient in one would be dog slow in another. This is also why various people recommend not porting a Windows driver to Linux, but to instead write a native Linux driver. Somebody presented a paper on the 10 things not to do while writing a Linux driver.
Notice, that I2C is also how lots of Linux drivers are written for block devices, because lots of block devices have a high layer, a mid layer, and a low level. Normally the high level, and mid layer are similar between lots of drivers, and generally get squeezed into a single driver.
Kirby
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.