The announcement of a new project 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 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.  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 [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



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

• Archive of above thread
• KernelTrap interview with Alan Cox