The battle for wireless network drivers

[Valour]

BSD and Linux programmers have had a lot of success in creating drivers for new computer hardware in a timely manner, but much of their effort has been without the support of major hardware manufacturers. Intel, Marvell, Texas Instruments and Broadcom, though separate and competing entities, seem by one consent to prevent non-Microsoft operating systems from working properly with some of their most widely-used network chips. To find out more about this situation, I interviewed representatives from network chip manufacturers and programmers from free software operating systems. Their answers are below.

The battle for wireless network drivers

[seagull_065]

Thanks for the great article.

I think consumers need to be more concerned about the companies they buy products from. Articles like this help to keep us informed.

[J.F.]

I think half the problem is that writing drivers for Windows is a market that favors those few who have learned how to do it. They charge through the nose for their expertise, and companies often feel that given how hard and expensive Windows drivers are to make, they can't do anything to make it easier and less expensive for their competitors.

For example, some years back, we contacted a programmer who did Windows printer drivers about getting a printer driver for our product. He wanted $35K up front for a binary, and a cut of each product sold. Getting source would be an additional $100K, and even then, he kept strict control of the code. I have the feeling that this is still how things go in the Windows market, and rather than make things easier and cheaper for everybody, companies are willing to kowtow to programmers out to gouge the market. So a few Windows programmers are making things hard on everybody.

[Valour]

I got the impression from the people I talked to that some or most of the wireless chip manufacturers outsource their firmware development to other companies. In an effort to save money, they outsource as much as possible so they don't have to pay engineers and build manufacturing plants. In return, they get a working product at a low price, but limited rights to source code for firmware or drivers. Some people emailed me privately and claimed inside knowledge that this is why Marvell can't allow firmware redistribution or access to documentation -- they don't have the rights to give you the stuff in the first place. I'd love to have Marvell verify that claim, but I can't seem to contact a company representative.

[J.F.]

Remember that the EU courts said that MS's network protocol documentation was unusable... well, ALL of MS's documentation and examples are in the same shape. Functions are often undocumented, and if they ARE documented, the description is often misleading or even incorrect. Examples often don't compile, and if they do are full of bugs.

Companies which have programmers who have learned how to make functioning drivers have the Windows market over a barrel and know it. They aren't going to give up their cash cow for a few alternative OS people.

[Kirk Badger]

A major compliment for Jem Matzan for the Wireless Network driver article. Finally someone has explained this issue in a reasonably clear and commonsense manner.
In my experience wireless cards are rather difficult to set up in Linux except if they are native to the distro - which limits your choice of distro and wireless card.
Lots of claims but they seldom seem to install.
If they do off the fly it is wonderfull but the rest of the time lol.
The advanced wireless utulities seem to be written in Linux with the Windows versions behind the times but at least more useable.
Thanks again . I will read more of this author's articles.
I hope that they are a 1/3 as helpfull as the wireless driver one.

[Valour]

I'm glad you liked the article. It took quite a lot of work to get it published -- more than any other article I've written, I think. It was easy to write, though, because like every other computer user, I have a personal interest in seeing wireless drivers become less of a hassle to install and use. Unfortunately there is a general attitude of tolerance and helplessness among users -- they feel that they have no choice but to put up with hardware manufacturer shenanigans. As the article shows, manufacturers have two very different attitudes toward users. I wish it were easier to know which chip you were buying with which card, though.

[mvw]

The problem with that article is that you have not been able to talk to one of the key developers. E.g. interesting would have been if you could have interviewed Sam Leffler, the guy who wrote the Atheros driver (under contract) for FreeBSD and who seems to have been involved into the linux madwifi project.

As far as I know, and I am no expert, there are several arguments pro closed drivers:

- The company fears to expose trade secrets that give them an advantage in a fierce competition (this probably is likely for nvidia's graphics drivers)

- Some parts are forbidden to twiddle with. In case of Wifi cards end users are not supposed to meddle with the table of allowed frequencies. Each country has different frequencies that are allowed. Thus a vendor has two options:
1. put some piece of country-specific ROM on each different card (e.g. the freqs are different in the US and in Germany), which is expensive and probably much hassle
2. wire the table into software and just release a binary (this is what seems to have happened with the Atheros driver)

- Hardware has often design flaws which is circumvented by software and the company fears bad reputation (If I remember right a very popular realtek network chip was such a bad designed piece of hardware :-)

- Open source drivers might have bugs and the company fears this will reflect bad on the product (might happen, but I can't remember a prominent case)

- Company fears that source code would expose code that might violate other companies' patents (this rumored to be true in the graphic market)

Regards,
Marc

[jnash2001]

Theo de Raadt gave this presentation at OpenCon 2006 about "why hardware documentation matters so much and why it is so hard to get".
Highly recommended.

[otaku42]

As one of the MadWifi developers, I'd like to respond on the part of the article that refers to "my" project:

Mysteriously, it has virtually no support from the Madwifi Project, which is the development team responsible for creating Atheros drivers for Linux-based operating systems.

Wrong. We have madwifi-old-openhal as well as dadwifi-openhal branches in our repository, and the person who actively ports OpenHAL to Linux - Nick Kossifidis - works directly in that repository.

Of course, there is still a lot of work to do, but Rome wasn't built in one day. Since the HAL is an integral part of the driver switching to another HAL variant is a complicated task and can not be expected to happen instantly.

Madwifi continues to primarily support the proprietary Atheros HAL,

What else should we do in your oppinion? Cut the support for the binary-only HAL and leave the users in the rain while the integration of OpenHAL into MadWifi is worked on? This is not the way we want to deal with the users of our driver.

To explain: we're currently evaluating various options to come to a state where - in the far away future - MadWifi would be accepted for inclusion into the mainline Linux kernel. One of the necessary milestones will be to provide a OSS-compatible solution to the current binary-only HAL, and one of the evaluated options is inclusion of OpenHAL. This work is carried out in the above mentioned branches of the repository.

Until that work is completed and a final decision on which way to go has been made, it obviously makes no sense to drop the current (and working) driver variant that relies on the critizised binary-only HAL.

though there is an old and uninformative page in the Madwifi Wiki about it.

Old? Looking at the history, the page has been created "10/18/06", telling the interested reader that it's just a little more than two months old.

Uninformative? Well, we aren't perfect and we can't fight on all fronts at the same time (please don't forget that none of us is paid for the work on the driver).
After all: it's a wiki. Users are welcome to contribute text that makes the page better understandable. Questions on that topic will be answered as our time and knowledge allows when they are sent to one of the known mailing lists.

The email addresses listed for the Madwifi developers either bounce

Which of the given addresses bounced, and where and why? At least the one from me does definitely not bounce (unless the IP of the sending mail server is listed either in list.dsbl.org, safe.dnsbl.sorbs.net or sbl-xbl.spamhaus.org). Even then there's always the mailing lists as a possibility to get in contact with the team, if other ways fail - an option that was not used, as far as I can see.

or elicit no response to requests

I can not speak for the others on the team, but I'm quite sure I didn't get a request from the person who wrote the article on my published mail addresses. Obviously, I can not respond to something I didn't get.

for comments on why there is no apparent effort to use the open source HAL in Madwifi.

This part of the sentence shows that the article has, at least partially, been badly researched. There were some extensive discussions in madwifi-devel as well as netdev about integrating OpenHAL into MadWifi during the last weeks, and at least madwifi-old-openhal has been updated several times during the last days.

It may very well be pressure from Atheros that keeps ar5k out of Madwifi,

Bullshit. Atheros didn't put any pressure on us, neither in terms of development decisions nor in other terms.

but no one at Madwifi or Atheros would talk to me about it.

Again: it's hard to respond if one is not asked.