Intel PRO/Wireless 3945ABG Network Connection

Intel is pleased to announce the launch of an open source project to support the Intel PRO/Wireless 3945ABG Network Connection mini-PCI express adapter (IPW3945).

The project is hosted at http://ipw3945.sourceforge.net. A development mailing list is available (linked from the top of the IPW3945 project page.) You can find the current development release for the adapter by following the links on the project home page.

A stable [end user targetted] version is not yet available. Those interested in using the development version should review the notice linked to from the project page. A stable version should be available in the next few weeks.

Aside from a form factor change (our prior wireless cards were mini PCI while this one is mini PCI express), this project has also changed the division of work between what occurs on the adapter and what the host is responsible for performing. The microcode and hardware provide lower level MAC services (timings, backoffs, transmit queue management, etc.) The host is responsible for middle and upper layer MAC services.

As a result of this change, some of the capabilities currently required to be provided on the host include enforcement of regulatory limits for the radio transmitter (radio calibration, transmit power, valid channels, 802.11h, etc.) In order to meet the requirements of all geographies into which our adapters ship (over 100 countries) we have placed the regulatory enforcement logic into a user space daemon that we provide as a binary under the same license agreement as the microcode. We provide that binary pre-compiled as both a 32-bit and 64-bit application. The daemon utilizes a sysfs interface exposed by the driver in order to communicate with the hardware and configure the required regulatory parameters.

Those familiar with our prior projects may be pleased with the changes we have made with the license agreement for binary portions of this new project. We were able to provide a more easily understood agreement for the binary components required for the adapter to function. While this new license still restricts against reverse engineering and modification, it has been changed to allow easier redistribution. You can find the terms of the agreement accessible from the microcode and daemon download page linked to from the project site.

The current development snapshot contains backward compatibility code to allow the driver to work in older kernels. We will be removing that code prior to submitting the driver for inclusion in the kernel.

Thanks,
James

Awesome. Now all we need is someone to write the bcm series for wireless and ndiswrapper can go away.

Jeff

What, eh? We have a bcm43xx driver. Or what do you mean?

Greetings Michael.

Cool!

It was exciting to watch the "centrino" wireless cards go from the least supported cards in the Linux to the near the best G and A cards from a feature and licensing stand point (modulo the firmware restart issues).

I have a ipw2200 and have recommended it and now the ipw2915 to anyone who has asked (myself and ipw2xxx using co-workers have taught thousands of students and decision makers in Linux classes worldwide).

It is very disappointing to see this binary user space daemon (that must run as root, presumably to write into /sys/) requirement. I recognize that it is a better poison than a binary kernel module.

At the point when I'm in the market for a mini-PCI express wireless adapter I hope there are other cards available that don't require any kernel or userland binary pieces. I'll vote with my wallet so to speak.

Dax Kelson
Guru Labs

the regualatory problems are not true. they are completely focused on the users. Someone who wants to change it can always do it, may it be by binary patching. I don't know of a single country that forbids implementing those bits in source code shipped, and in those countries we alredy couldn't distribute the kernel.

A binary daemon is completely unacceptable and unless you fix that there is zero chance the driver could get into mainline. I'd also like to urge the distributors to not put this crap in to weaken our free drivers future. Intel, please stop this madness and play by the rules.

As someone (a broadcast engineer with 40+ years of carrying what used to be a 1st phone) obviously more familiar with the FCC R&R than you apparently are, Christoph, I'll have to argue that point. Intel has no legal choice in the matter because the FCC had decreed that the stuff to enforce the radiation limits either has to be in a custom made for each country chip, or in binaries that check themselves for tampering by secure crc, md5sum or similar methods. If the modules crc changes, it must do an instant disable of the transmitter functions and exit or crash, thereby precluding any 'hot rodding' of the chipset.

So basicly, you can accept it with the wrappers Intel provides, or linux will not have access to the use of these devices, any of them that fit in the category of "software radios". Intel et all has NO choice in the matter in this country by FCC decree, and I believe its copycatted by the Canadien DOC by treaty. Other locales may change the rules slightly and often do, hence the requirement for manufacture of the software radio, one thats totally controlled by the software issued for that locale's use.

The fact that they are furnishing a wrapper, somewhat in the ndiswrapper style, says that Intel would like a piece of this market, but with the choice you are giving them with this arbitrary statement, they have no choice but to quietly fold up their tents and go home. You are asking Intel to break the laws designed to enforce the use of the 802-11 bands in a legal manner.

So you might want to rethink your objections. I agree that it should never become a piece of the kernel because it can't be audited, nor even dissed without a DMCA prosecution, but we've been using nvidia's stuff in modular fashion for quite some time, usually with decent results. Its up to the user to install it of course, but thats precisely the same scenario here with the Intel code. Intel will have to put it someplace where the *user* can download it, meaning a server setup someplace as opposed to handing the kernel developers one copy, but thats the breaks as we've chosen to do it. Intel will also be expected to supply a method of fileing bugs in case it doesn't work. A publicly postable list that is actually supported for any and all bug claims posted. Its an expense for intel of course but thats their price of having a dog in this fight.

Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Please stop spreading the bullshit. Please quote the FCC regulation on this.

We have support for other software radios. If intel doesn't do the right thing support for their hardware will have to wait until someone has reverse-engineered their daemon [1].

[1] they disallow it in their license, but that's completely void in many countries.

Its not "bullshit" as you so "eloquently" put it, Christoph. As for looking it up, I'd imagine your ability to run a search engine at fcc.gov exceeds mine. Hint, its probably in the section called "Rules that apply to all". These rules go back to about the time of when they outlawed any transmit tunability in CB radios in the later 70's, so its not a new item by any means as its just an extension of that edict to cover this newer technology. The fact that it effectively put a stop to conference call type use of single sideband because no 2 radios were on the same, now non-adjustable frequency was an undesirable thing, but thats the breaks. I might try and look it up after I've had some zz's, as I just came from doing transmitter maintainance overnight.

I don't think you'll find that to be the case here in the states.

Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Well, be it this or that way. I don't see how a binary blob is able to prevent that the user operates the device on illegal freqs. In fact, it is a void protection and is just inconvenient. An open source regdomain implementation is just as safe against modifications, as this binary blob. There is no point in doing this binary.
In fact, if you really want to prevent people from doing Something Bad (tm), you must take technologies such as Trusted Computing. And even that can, by the opinion of many people, circumvented somehow. The best way to prevent, that a device is driven on illegal freqs, is by not selling the device.

Greetings Michael.

I'm not really sure what you are describing but you probably want to reference CFR Title 47 Telecommunications [1]. Particularly interesting is 15.202 "Certified operating frequency range." which says in part:

"... Master devices marketed within the United States must be limited to operation on permissible part 15 frequencies. Client devices that can also act as master devices must meet the requirements of a master device. ..."

Also there is a general prohibition on "harmful interference" in 15.5 which says in part:

"(b) Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator. .."

I am going to guess that these two excerpts provide strong evidence that Intel has to keep their radios from being modified accidentally or purposefully. I also suspect that they only have to make it difficult for an end user and not a technologist. So the well defined interface between the closed source binary only userspace daemon and the open source kernel driver could be reverse engineered and an unencumbered replacement created.

I am definitely not a lawyer and this stuff is always subject to someone making an argument in court.

Stephen

[1] http://www.access.gpo.gov/nara/cfr/waisidx_05/47cfr15_05.html

Am Samstag 25 Februar 2006 11:53 schrieb Christoph Hellwig:

source_ driver and the binary user space daemon seems to be quite defined and unobfuscated. Obviously, someone owning the device has to verify that the daemon doesn't tamper the hardware beyond the driver's back.

There is a difference. As kernel developers, we can put the responsibility to verify that a device can be operated legally on the user, as you said. A manufacturer, especially a huge one as Intel, is obligated to take this burden from their customers - obligated may be by law, may be by company policy.

If someone else reverse engineers and replaces the daemon, it may not be Intel's problem anymore - but that's all not the point.

Actually, Intel invested a lot of time to avoid shipping a binary only driver or a HAL like madwifi does. So however this settles, they deserve at least to be adressed in a less insulting tone than you do in your mails.

Thanks,

Stefan

Would not it be easiest to have the chipset enforce the acceptable bands? So that software can't switch the chipset to 1337 GHz no matter how hard you forward/reverse-engineer it.

Jan Engelhardt

That removes the ability to legally use this chipset in regions other than the one its designed for. We tend to forget that a set of masks to make a chip, in the currently fabbing 90nm process, can ran as high as 50 million dollars for the more complex stuff. And it can only multiply when 45nm and even 15nm come online in the coming years. Such precision costs money, and must be recouped by sufficient volume of the single chip that mask set makes.

If Litchenstein has a different set of rules, I guarantee that there will NOT be a seperate chips masked out just for Litchenstein.

Sure, thats so ridiculous an example its sublime, but those are the facts that the chip makers must deal with on a global scale. Its much easier for them to furnish a binary only driver that enforces the rules for the region where the chip will be used. Economically, its the only choice they have. I'd be interested in how, if they supply binaries that could supposedly be downloaded to anyplace on the planet, do they enforce in software the miriad variations of the rules. It would have to have some means of discovering where it is in order to enable the proper subset of those rules. That however, is also proprietary info because of the potential for hackability if the method were known.

Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

But that is exactly the point. A binary only driver does not enforce something. It can easily be run though a disassembler, hooked at kernel level, modified with a hexeditor, rewritten as opensource... It is not worth the pain.

Greetings Michael.

Hi everybody,

Le Sat, 25 Feb 2006 15:19:40 +0100, Jan Engelhardt a écrit :

I will say, why not put the restriction of the firmware binary blob ? It run on the device so it will be difficult for people to analyse it.

Also the firmware could be on a eeprom and transparent for the user.

Matthieu

Matthieu> I will say, why not put the restriction of the firmware Matthieu> binary blob ? It run on the device so it will be difficult Matthieu> for people to analyse it.

So what do I do when I take my US laptop and fly to country X, which has comletely different rules for these radios? Do I have to re-flash my firmware to make it work properly?

The big problem is the lack of global unity, but that will slowly get fixes as more countries realize it's a problem. The big issue will be military/govt radio spectrum users, they won't want to move if they can help it.

John

Hi,

And what happen with the userspace binary blob ?

How it will know in which country you are ?
Does it access to a secret GPS on your computer ?

So there are 2 solutions :
- make the card work only for a country with a flag in a RO eeprom or in another place in the hardware (firmware, ....).
- make the card works on all the possible channels.

Also if the firmware need to be load each time you reset the card (this is the case with the current ipw2xxx implementation), you won't notice if you switch for a firmware for a country X to a firmware for a country Y.

Matthieu

I haven't looked at the driver code, but I would expect it to be like the ipw2200 where the "country" code is in eeprom, which sets a code specifying the region where it will work. If you take a given piece of hardware somewhere else in the world, it will likely not be in complience.

Larry

Intel has got the obligation to make sure they are not letting you use not allowed channels. If you as a manufacturer allow with a certain change to let people use the channels they want, you are actually encouraging people to use those channels. Letting the option available makes Intel liable to get sued. If you buy an US PC, you stick to the US channels. If you are a world traveler, buy the PC in japan or in Europe. Then, you will be able to use the US and ROW(Rest of World) channels.

This is just the way it works, else you are liable. Believe me, and not only me. Intel does not do things to give you a hard time, it is because of a reason and they have the best lawyers at it.

It is just the Law and the FCC's.

.Alejandro

They are although the binary interpretation isn't AFAIK from law but from lawyers. The same is actually true in much of the EU. The actual requirement is that the transmitting device must be reasonably tamperproof. Some of the lawyers have decided that for a software radio tamperproof means "binary".

Thats pretty dumb but given the hardware variant of this is "seal anything adjustible in plastic gunge" you can see the logic at work - and it *will* help make the product tamperproof to end users. Remember Christoph you are not an "end user" any more than hardware like that is designed to proof against a person who can use a scope and solder surface mount components.

Now a smart vendor would have put MD5 sum checking into the chip so you can only load register sets for the transmitter as a block and that block is loaded such that

[Data] + Secret known only to chip = MD5sum with data

or a similar cookie signing scheme. Replay attacks don't matter here so that should be sufficient.

Exactly. There's no strong requirement, it's just over-zealous corporate lawyers. That's why we need to push Intel strongly here.

It is not Intel, but the regulators that need a stronger clue. Vendors don't have any incentive to force change on this. They just want to sell as much hardware as possible.

Does anyone know who the actual FCC administrators in charge of this are?

i completely agree, besides, if this userspace binary blob just does something to /sys what is to prevent a user from doing that himself? what is to prevent someone to modify the driver slightly to smash a log entry every time the daemon does something?

the binary userspace daemon protects against nothing.

In the technical realm, true. In the legal realm, potentially false.

Jeff

Well, that means no luck to sparc users.... And I hope kernel<->user interface is nice, clean and documented.

Thanks, Sharp!

James Ketrenos <[email protected]> wrote:

| As a result of this change, some of the capabilities currently required
| to be provided on the host include enforcement of regulatory limits for
| the radio transmitter (radio calibration, transmit power, valid
| channels, 802.11h, etc.)  In order to meet the requirements of all
| geographies into which our adapters ship (over 100 countries) we have
| placed the regulatory enforcement logic into a user space daemon that
| we provide as a binary under the same license agreement as the
| microcode.  We provide that binary pre-compiled as both a 32-bit and
| 64-bit application.  The daemon utilizes a sysfs interface exposed by
| the driver in order to communicate with the hardware and configure the
| required regulatory parameters.

I fail to see how a binary-only daemon can be used to enforce regulatory limits. What stops a user from running a daemon for another country, enforcing different limits?

Dick Streefland                      ////                      Altium BV
[email protected]           (@ @)          http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------