The Battle for Wireless Network Drivers

An anonymous reader points out this Jem Matzan article "about the pain Linux and BSD programmers have in trying to obtain/write device drivers for various wireless cards," writing: This article also has a fairly detailed explanation of how wireless firmwares and drivers work. Two of the manufacturers are actively working with the FOSS community without requiring an NDA."

Comments

As someone that has been there

[mycal]

Trying to develop wireless 802.11 interfaces for embedded platforms I agree that it is a total pain in a arse. I even knew people that I worked with before at broadcom and couldn't get them to kick down the Software API. We finally got a Philips BGW200 system working and that wasn't easy either since even after filling out NDAs we got messed around for a few months trying to get the right documentation.

But now it does seem that Atmel is working with people, and accourding to the article so is raylink.

What you can do to help is if you have choice, support these guys when you have to buy a wireless adapter even if it is a few bucks more.

-M

I know what IBM will do. I don't know why.

[quiberon2]

If you want (say) a disk controller subsystem from IBM, then IBM will generelly supply the adapter microcode as 'Object Code Only, All Rights Reserved'; and the device driver as open-source.

I don't know about redistribution rights; you can always ask.

If an open-source developer wants to see the source for the adapter microcode, ask about that one too.

There's more needed than just documentation

[Freggy]

Still I have the impression that lack of manufacturer willingness to publish documentation, is abused all too often to explain that there are no drivers for Linux, while the reality shows some other interesting facts. Here are some of my experiences I had with wireless in Linux:

• First I bought a card based on fullmac prism54 chipset. It was known as one of the best supported chipsets in Linux, at the time the only 802.11g driver included in Linux kernel IIRC. It worked fine for basic operation yes, but it did not seem to support WPA. Prism54 development seems to be halted completely already for some time. People are developing the islsm driver which would also support freemac cards, but this is far from usable at the moment.
• Intel Centrino ipw2200: had this in my laptop. Just installing firmware (which was as easy as adding PLF repository to my Mandriva system and running urpmi ipw2200-firmware) and it worked perfectly, WPA included!
• Ralink rt2500 based PC card: I bought this again because I knew the manufacturer published documentation. Well, actually there are two drivers. The legacy driver, which should be somewhat stable, but which you cannot use when using multi-processor (dual core, etc), and the new driver which is beta and still unstable. Well, I tried both, but did not succeed in getting my wireless network to work.
• Broadcom 43xx based PC card: was known at the time as one of the worst chipsets for Linux, because Broadcom was unwilling to publish documentation. Still bought it, because a new reverse engineering project started at that time. Today with kernel 2.6.19, this driver is included in Linux. And it works very good, WPA included. Yes, I had to install firmware by hand by means of bcm-fwcutter.

So I'm arriving at the bizarre conclusion that for me, the best working wireless chipsets, are these from the category of manufacturers that are not very willing to work together with community. Still, there's a free driver, with only the firmware being proprietary and not freely distributable. Other drivers which should be in the recommended category, failed for me. Some reflections:

• Good Linux support depends of much more than just the manufacturer publishing documentation. There should be an active community of developers: if that is lacking, even with good documentation, support will remain problematic.
• Even without documentation it is possible to create good drivers by means of reverse engineering. If a card is popular enough and the right people at the right time start reverse engineering, then this could be a big success.
• The presence of a proprietary, non-free driver could harm development of a free driver. For example take a look at the nvidia driver. Since a year, there's a reverse-engineering project to create a free dri-driver for nvidia, but it's not advancing at all. I guess lack of developer interest, because there's already the proprietary driver. Also look at ipw2945 driver: OpenBSD proved it can work without the the Intel binary-only daemon, but for Linux, nobody cared to reverse engineer it.

Re:Is the FCC the cause?

[doj8]

> Another possible answer could be that not all vendors agree
> on the interpretation of the requirements.

Likely this is true.

In the case of IBM (now Lenovo), their laptops will not boot with a non-IBM-certified wireless mini-PCI card in the system. Their interpretation of the FCC regulations is that the complete laptop, with wireless card, is FCC-certified. Installing a different wireless card, even though it is a standard component, even from IBM itself, and has been FCC-certified by itself, in IBM's opinion, makes the entire laptop no longer certified. Therefore, they must prevent the now non-certified laptop from working so as to meet FCC compliance.

It is a singular interpretation of the rules, as far as I know. There is a simple third-party fix to poke a byte to disable the check, so it can be worked around, but is still aggravating.

While a bit off-topic to wireless drivers, this example shows that the rules are subject to such extreme interpretation. I can easily see the legal department of Intel, et al, deciding some rule would break FCC compliance and thus preventing open sourcing the driver or even making the specifications available.