[Announce] Intel PRO/Wireless 3945ABG Network Connection

[Announce] Intel PRO/Wireless 3945ABG Network Connection

[James Ketrenos]

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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Dax Kelson]

On Fri, 2006-02-24 at 16:29 -0600, James Ketrenos wrote:
> 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).

Cool!

>   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.

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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Jeff V. Merkey]

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

Jeff

James Ketrenos wrote:

>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
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Michael Buesch]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

On Saturday 25 February 2006 00:48, you wrote:
> 
> Awesome. Now all we need is someone to write the bcm series for wireless 
> and ndiswrapper
> can go away.

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

-- 
Greetings Michael.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Christoph Hellwig]

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.

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Gene Heskett]

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.

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Christoph Hellwig]

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.

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Gene Heskett]

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.

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Michael Buesch]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

On Saturday 25 February 2006 12:19, Gene Heskett wrote:
> 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.

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Stephen Evanchik]

On 2/25/06, Gene Heskett <gene.heskett@verizon.net> 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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Stefan Rompf]

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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Jan Engelhardt]

>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.
>
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
-- 

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Matthieu CASTET]

Hi everybody,

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

>>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.
>>
> 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.
> 
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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[John Stoffel]

>>>>> "Matthieu" == Matthieu CASTET <castet.matthieu@free.fr> writes:

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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[matthieu castet]

Hi,

John Stoffel wrote:
>>>>>>"Matthieu" == Matthieu CASTET <castet.matthieu@free.fr> writes:
> 
> 
> 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?  
> 
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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Larry Finger]

matthieu castet wrote:
> 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.

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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Alejandro Bonilla]

On Sat, 2006-02-25 at 17:19 -0500, John Stoffel wrote:
> >>>>> "Matthieu" == Matthieu CASTET <castet.matthieu@free.fr> writes:
> 
> 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?  

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

> 
> 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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Alan Cox]

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.

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Christoph Hellwig]

On Sun, Feb 26, 2006 at 12:58:02AM +0000, Alan Cox wrote:
> 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".

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

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Stephen Hemminger]

On Mon, 27 Feb 2006 17:10:29 +0000
Christoph Hellwig <hch@infradead.org> wrote:

> On Sun, Feb 26, 2006 at 12:58:02AM +0000, Alan Cox wrote:
> > 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".
> 
> 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?

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Kasper Sandberg]

On Mon, 2006-02-27 at 17:10 +0000, Christoph Hellwig wrote:
> On Sun, Feb 26, 2006 at 12:58:02AM +0000, Alan Cox wrote:
> > 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".
> 
> Exactly.  There's no strong requirement, it's just over-zealous corporate
> lawyers.  That's why we need to push Intel strongly here.
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.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Jeff Garzik]

Kasper Sandberg wrote:
> the binary userspace daemon protects against nothing.

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

	Jeff

Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection

[Pavel Machek]

> 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.

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

-- 
Thanks, Sharp!