login
Header Space

 
 

OpenBSD: wpi, A Blob Free Intel PRO/Wireless 3945ABG Driver

May 28, 2006 - 6:26pm
Submitted by Jeremy on May 28, 2006 - 6:26pm.
OpenBSD news

Damien Bergamini [interview] recently announced wpi(4), "a blob-free driver for Intel PRO/Wireless 3945ABG 802.11 adapters as found in Centrino Duo laptops" for OpenBSD. His announcement came a little over two months after Intel released the controversial ipw3945 driver for Linux [story] which included a binary-only daemon described as necessary for enforcing regulatory limits for the radio transmitter on the wireless device. Curious to know more about Damien's efforts, I approached him for more information, asking him how his driver differs from the Linux driver.

Damien began, "the wpi(4) driver I committed in OpenBSD is a totally new driver which doesn't use any bits from Intel's ipw3945 driver for Linux and doesn't rely on any binary-only components," though the driver does require the firmware provided by Intel. He explained that in his reverse engineering effort he only referred to the Linux driver to determine things like register offsets, "I just instrumented the GPL'd part of the driver (which is of course perfectly legal) to display which commands were sent to the firmware. And it turned out to be very simple," adding, "I never tried to disassemble the binary only regulatory daemon, which the license prevents." In reviewing the GPL'd driver, Damien described it as unnecessarily complex with 18,000 lines of code "just for a wrapper around a firmware and a binary blob." In contrast, the OpenBSD driver is 3,000 lines of code, "I do my best to write drivers that are easy to read and simple to understand so that other developers can join the fun and help to improve them."


ipw3945 Linux Driver
The existence of a binary-only userland daemon for enforcing regulatory compliance as included with the ipw3945 Linux driver is unique among Intel 802.11 wireless network drivers. Damien explained that in previous drivers compliance was enforced by the firmware, "which probably got the region information from the onboard EEPROM." When asked why he thought Intel moved this responsibility out of the firmware, Damien replied that he wasn't sure, going on to suggest, "probably because they wanted to reduce the complexity of their firmware which were bloated and buggy."

"It is amazing how poorly this driver is designed," Damien commented about the ipw3945 Linux driver, describing how the interface between the driver and the binary-only daemon adds "a spectacular amount of complexity". He also noted that the driver doesn't use much of the Linux 802.11 stack, which was partially contributed by Intel, "they duplicate large portions of code and implement things directly in the driver that should belong to the 802.11 stack. I found it surprising coming from Intel since they've shown numerous times in the past that they can write high-quality code."

In his efforts to understand how the ipw3945 driver controls the firmware, Damien found that the binary daemon was simple to bypass, offering no real control. "I was able to make the daemon think it was in another regulatory domain," he explained, "just by adding a few lines of code into the GPL'd part of the driver." The binary-only daemon is described as necessary due to FCC regulations, causing Damien to retort, "I think Intel (and Atheros) use FCC rules as a pretext to hide intellectual property in the binary-only portions of their drivers." He went on to explain that the Intel regulatory daemon, as well as the Atheros HAL, implement a number of complex algorithms, including automatic calibration of the radio power based on temperature variations, and dynamic tuning of the radio sensitivity based on received signal strength. "These algorithms go far beyond the simple enforcement of regulatory compliance," he added, "and can really make the difference by extending the operating range of the adapter, improving throughput in various environmental conditions, and reducing power consumption. That is why vendors want to keep these algorithms secret."

Damien noted that it doesn't bother him that companies don't want to reveal all of their source code, "but what annoys me is that they still pretend to provide open source drivers while you only have access to the part of the code that drives the MAC and communicates with the blob."

Porting wpi
When asked the likelihood that the wpi driver would be ported to Linux, Damien thought that this was unlikely. "I doubt the Linux community will ever leverage this work since Intel is developing a 802.11 layer for the Linux kernel," he said, "Linux kernel developers probably can't afford to upset Intel." He also pointed out that the blob-based driver is already in wide use among Linux distributions, "and the worst thing is that most users of these distributions will not even notice they're running some binary only stuff that has privileged access to the kernel because it's completely silent."

wpi Status:
The wpi driver is not yet finished. "Basic operations work but performance is less than optimal," Damien explained. "I'll now work on improving the driver by using a better rate control algorithm and adding dynamic tuning of the radio sensitivity and transmit power." He pointed out that this will likely be one of the first open source implementations of these algorithms, an effort that will benefit other wireless drivers.

The wpi driver does not utilize a userland daemon to comply with FCC regulations. Instead enforcement is left to the driver, "with the regulatory domain and the maximum transmit power settings for each channel stored in EEPROM," Damien explained, "it's simple for the driver to enforce the regulations directly inside the kernel." He went on to add, "of course, if people want to bypass them by modifying the driver's source code, they can. But it's not different with Intel's binary only daemon as you can easily fool it into thinking it is in another regulatory domain by just lying about the EEPROM content."

The initial wpi driver was merged into the OpenBSD source tree on May 14, 2006:

CVSROOT:        /cvs
Module name:    src
Changes by:     damien [email blocked]  2006/05/14 13:00:51

Modified files:
        sys/dev/pci    : files.pci 
        share/man/man4 : Makefile 
Added files:
        sys/dev/pci    : if_wpi.c if_wpireg.h if_wpivar.h 
        share/man/man4 : wpi.4 

Log message:
Initial import of wpi(4), a blob-free driver for Intel PRO/Wireless 3945ABG
802.11 adapters as found in Centrino Duo laptops.
More to come but works well enough for me to commit this over a wpi(4).

"Intel is developing a 802.11

May 29, 2006 - 10:14am
Anonymous (not verified)

"Intel is developing a 802.11 layer for the Linux kernel"
Since when ? The current real 802.11 stack is developed voluntarily by people from e.g. the bcm43xx project. And the plan is to eventually switch to the devicescape stack.

The 802.11 stack that is curr

May 29, 2006 - 12:25pm
Anonymous (not verified)

The 802.11 stack that is currently in Linux is developed mainly by Intel (grep -i intel net/ieee80211/*).
The latest version being available on sourceforge: http://ieee80211.sourceforge.net/
I don't think there is a consensus between Linux kernel developers to switch to devicescape yet.

AFAIK the consensus is there,

May 31, 2006 - 11:20am
Anonymous (not verified)

AFAIK the consensus is there, devicescape stack is on its way. Anyways, that claim is by far not true, intel developed their driver and their "stack" is more-or-less just a few header files. The real work is done by bcm43xx people (softmac) and others.

Wether that is true or not, t

May 29, 2006 - 2:14pm
Anonymous (not verified)

Wether that is true or not, the phrase "Linux kernel developers probably can't afford to upset Intel" is pure bullshit. Linux developers are just as interested as this guy in open source.

If true, it would be really n

May 31, 2006 - 11:01pm
Anonymous (not verified)

If true, it would be really nice to see a lot more of them take a firm public stance against closed, proprietary drivers in Linux.

If no one else, I would like

May 29, 2006 - 10:41am
Anonymous (not verified)

If no one else, I would like to see Debian port this to the Linux kernel. Seems in keeping with their focus on trully free software.

But it would be under the BSD

May 29, 2006 - 1:36pm
Anonymous (not verified)

But it would be under the BSD license?

It depends whether it is simp

May 29, 2006 - 1:46pm

It depends whether it is simply used as a reference, or modified directly to work on Linux... I would think, if someone were to use it as a base for a new Linux driver (I would, but I lack a notebook with MiniPCI-E) that it should be dual GPL/BSD licensed as a gesture of good will and to promote code sharing...

(The really impressive thing is how small and clean Damien's driver is. Kudos to him. I'm constantly impressed by the level of kernel code quality in OpenBSD.)

What's this nonsense about du

May 29, 2006 - 2:48pm
Anonymous (not verified)

What's this nonsense about dual licensing? Just leave the code BSD licensed and you've no possible problems, BSD's already more liberal than the GPL.

you can simply relicence it..

May 29, 2006 - 10:57pm
Anonymous (not verified)

you can simply relicence it... that's the beauty of the BSD licence. As long as you leave in the original copyright (author/date) string, you can change the licence.

You don't relicense it, only

May 29, 2006 - 11:34pm
Anonymous (not verified)

You don't relicense it, only the copyright owner can do that. You just combine it in a non-BSD licensed work. Contact a lawyer if you need this explained in more layman terms.

Plus out of goodwill as said,

May 30, 2006 - 2:12pm

Plus out of goodwill as said, if you're modifying some code which is originally BSD licensed, it would be nice (but is not required of course) that the modification would be under the BSD license: this could ease the maintenance..

The part about the 'tuning of sensitivity' reminds me of the printer where OSS developpers made their own implementation of color management algorithm and want/need only access to the "raw" capability of the printer (which is not so easy to get :-(), Damien Bergamini work could lead to the same situation..

> the worst thing is that mos

June 4, 2006 - 1:53am
Anonymous (not verified)

> the worst thing is that most users of these distributions will not even notice >they're running some binary only stuff that has privileged access to the kernel >because it's completely silent."

bullshit, "modprobe" warn when any not open source modules loaded.

>. "I doubt the Linux community will ever leverage this work since Intel is >developing a 802.11 layer for the Linux kernel," he said, "Linux kernel developers >probably can't afford to upset Intel."

bullshit, people just do not do the same work again,
for OpenBSD there is no driver, so they write their own,
for linux there is working solution, why do it again?

> bullshit, "modprobe" warn w

June 5, 2006 - 11:23am
Anonymous (not verified)

bullshit, "modprobe" warn when any not open source modules loaded.

Learn how to read. This is not a kernel module but a userland daemon, so modprobe doesn't apply here. And the daemon warns nothing.

for linux there is working solution, why do it again?

Because it's not open-source, it's not free, and it's crappy.
Before Linux, there were working operating systems solutions, so why do it again?

modprobe doesn't issue any wa

June 13, 2006 - 8:47am
squiggleslash (not verified)

modprobe doesn't issue any warnings because Intel made the kernel-space side of the driver "open source" (right down to there actually being a Sourceforge project to maintain it.) This isn't like the infamous fglrx ATI-video driver.

There are various issues when it comes to redistributing drivers with a significant binary-only part, especially on a system like GNU/Linux where an upgrade to glibc can, theoretically, break many things (GNU/Linux has gone through two major "upgrades" in the last ten years that destroyed binary compatability - one was the a.out to ELF transition, the other was the libc to glibc transition. This is a real issue, and this chipset will probably appear in laptops for the next year or two.); so even if you don't care about issues unless given pseudo-practical arguments, it's obvious that a driver that relies upon a binary is not an adequate long-term proposition.

Intels drivers ARE shitty

June 29, 2006 - 6:46am
Anonymous (not verified)

I work with Intels XScale, which is an ARM processor. It's for embedded systems, and the persistent storage is just 16MB (NAND flash, IIRC).

Now get this: in order to get the built-in ethernet ports to work with Linux, I need to build and a load a so-called access library, the kernel driver and firmware. They amount to around 1MB ! I need to load 1 Megabyte just to get ethernet ! My whole kernel is almost exactly as big. Talk about bloat ! This wouldn't be so bad if it were on a desktop with multi-gigabyte harddisk, but I only have 16MB for the whole system, and 1/16th is already gone for the ethernet driver !

They surely are a bunch of very clueless people...

There is an alternative

January 31, 2007 - 4:14am
Anonymous (not verified)

Still experimental iwlwifi driver works without binary-only daemon.

http://bughost.org/iwlwifi/

Quick glance at the code shows that iwlwifi is based on ipw3945 driver and is still a bit complex compared to OpenBSD wpi driver.

I tried it today and it

February 11, 2007 - 11:18am
Anonymous (not verified)

I tried it today and it worked... somehow ;-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary