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
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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
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
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.
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.
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.
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.
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
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.
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.
>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
--
On Saturday 25 February 2006 09:19, Jan Engelhardt wrote:
>>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.
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.
>Jan Engelhardt
--
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.
On Saturday 25 February 2006 20:09, Gene Heskett wrote:
> 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.
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?:
>>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
>>>>> "Matthieu" == Matthieu CASTET <[email protected]> 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
Hi,
John Stoffel wrote:
>>>>>>"Matthieu" == Matthieu CASTET <[email protected]> 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
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
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.
On 2/25/06, Gene Heskett <[email protected]> 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
On Sat, 2006-02-25 at 17:19 -0500, John Stoffel wrote:
> >>>>> "Matthieu" == Matthieu CASTET <[email protected]> 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
> 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!
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---------------------------
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.
On Mon, 27 Feb 2006 17:10:29 +0000
Christoph Hellwig <[email protected]> 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?
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Kasper Sandberg wrote:
> the binary userspace daemon protects against nothing.
In the technical realm, true. In the legal realm, potentially false.
Jeff