The announcement of a new project [1] to support Intel's PRO/Wireless 3945ABG Network Connection mini-PCI express adapter (IPW3945) was met with mixed reactions. The project includes a binary-only daemon to enforce regulatory limits for the radio transmitter on the wireless device, communicating to the kernel driver through a sysfs interface. In the announcement, James Ketrenos describes the licensing [2] of the binary daemon, "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."
Christoph Hellwig criticized the binary-portion of the project, "the regualatory problems are not true". He pointed out that even a binary can be patched, suggesting that releasing source code for the daemon would still comply with regulations. He went on, "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." Gene Heskett disagreed, "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." Alan Cox acknowledged the regulations, but concluded, "...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'."
From: James Ketrenos [email blocked] To: NetDev [email blocked], linux-kernel [email blocked] Subject: [Announce] Intel PRO/Wireless 3945ABG Network Connection Date: Fri, 24 Feb 2006 16:29:58 -0600 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 [3]. 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
From: Christoph Hellwig [email blocked] Subject: Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection Date: Sat, 25 Feb 2006 08:41:39 +0000 On Fri, Feb 24, 2006 at 04:29:58PM -0600, James Ketrenos 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 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.
From: Alan Cox [4] [email blocked] Subject: Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection Date: Sun, 26 Feb 2006 00:58:02 +0000 On Sad, 2006-02-25 at 08:41 +0000, Christoph Hellwig wrote: > the regualatory problems are not true. 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.
From: Gene Heskett [email blocked] Subject: Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection Date: Sat, 25 Feb 2006 05:49:47 -0500 On Saturday 25 February 2006 03:41, Christoph Hellwig wrote: >On Fri, Feb 24, 2006 at 04:29:58PM -0600, James Ketrenos 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 > >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.
From: Christoph Hellwig [email blocked] Subject: Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection Date: Sat, 25 Feb 2006 10:53:40 +0000 On Sat, Feb 25, 2006 at 05:49:47AM -0500, Gene Heskett wrote: > 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. Please stop spreading the bullshit. Please quote the FCC regulation on this. > 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". 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.
From: Gene Heskett [email blocked] Subject: Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection Date: Sat, 25 Feb 2006 06:19:04 -0500 On Saturday 25 February 2006 05:53, Christoph Hellwig wrote: >On Sat, Feb 25, 2006 at 05:49:47AM -0500, Gene Heskett wrote: >> 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. > >Please stop spreading the bullshit. Please quote the FCC regulation > on this. 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. >> 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". > >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. 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.
From: "Stephen Evanchik" [email blocked] Subject: Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection Date: Sat, 25 Feb 2006 20:09:38 -0500 On 2/25/06, Gene Heskett [email blocked] wrote: > 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'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 [5]
From: Stefan Rompf [email blocked] Subject: Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection Date: Sat, 25 Feb 2006 13:29:03 +0100 Am Samstag 25 Februar 2006 11:53 schrieb Christoph Hellwig: From a short glance over the driver code, the protocol between the _open 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. > We have support for other software radios. 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 intel doesn't do the right > thing support for their hardware will have to wait until someone has > reverse-engineered their daemon [1]. 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
Related Links:
- Archive of above thread [6]
- KernelTrap interview with Alan Cox [7]