Will there be Intel Wireless 3945ABG support?

Will there be Intel Wireless 3945ABG support?

[Joseph Michael Smidt]

Will 2.6.18 or 2.6.19 support Intel Wireless 3945ABG?  Please cc me since I am not subscribed.   Thanks.

                            Joseph Smidt
------------------------------------------------------------------------
Joseph Smidt

422 Wymount
Provo, UT 84604
phone: 801-371-5564
email: jsmidt@byu.edu

Re: Will there be Intel Wireless 3945ABG support?

[Otavio Salvador]

"Joseph Michael Smidt" <jsmidt@byu.edu> writes:

> Will 2.6.18 or 2.6.19 support Intel Wireless 3945ABG?  Please cc me
> since I am not subscribed.  Thanks.

There's a module available[1] for us but it's not merged in mainline yet.

1. http://ipw3945.sourceforge.net/

You could use it in meanwhile.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: Will there be Intel Wireless 3945ABG support?

[John W. Linville]

On Tue, Jul 11, 2006 at 10:32:43AM -0600, Joseph Michael Smidt wrote:
> Will 2.6.18 or 2.6.19 support Intel Wireless 3945ABG?  Please cc me since I am not subscribed.   Thanks.

It will not be in 2.6.18.  Making 2.6.19 is not out of the question,
but it may take some work.

Hth!

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Will there be Intel Wireless 3945ABG support?

[Alistair John Strachan]

On Tuesday 11 July 2006 18:12, John W. Linville wrote:
> On Tue, Jul 11, 2006 at 10:32:43AM -0600, Joseph Michael Smidt wrote:
> > Will 2.6.18 or 2.6.19 support Intel Wireless 3945ABG?  Please cc me since
> > I am not subscribed.   Thanks.
>
> It will not be in 2.6.18.  Making 2.6.19 is not out of the question,
> but it may take some work.

Has some agreement been met regarding the mandatory use of the binary 
regulatory daemon? The webpage seems to suggest it is still necessary, and 
I'm sure that would disqualify merging the driver with Linux proper.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Will there be Intel Wireless 3945ABG support?

[Alon Bar-Lev]

Alistair John Strachan wrote:
> On Tuesday 11 July 2006 18:12, John W. Linville wrote:
>> On Tue, Jul 11, 2006 at 10:32:43AM -0600, Joseph Michael Smidt wrote:
>>> Will 2.6.18 or 2.6.19 support Intel Wireless 3945ABG?  Please cc me since
>>> I am not subscribed.   Thanks.
>> It will not be in 2.6.18.  Making 2.6.19 is not out of the question,
>> but it may take some work.
> 
> Has some agreement been met regarding the mandatory use of the binary 
> regulatory daemon? The webpage seems to suggest it is still necessary, and 
> I'm sure that would disqualify merging the driver with Linux proper.
> 

Why not?
The whole point is running a system that you know you can support for many years,
even without a vendor support...
And to have a system that you know exactly what running in it...
Having a binary closed source violate this.

Also there is no good reason why supplying this daemon as closed source... All they
wish is people don't mess with their frequencies, and sooner or later someone will...

Best Regards,
Alon Bar-Lev.

Re: Will there be Intel Wireless 3945ABG support?

[Alistair John Strachan]

On Tuesday 11 July 2006 19:25, Alon Bar-Lev wrote:
> Alistair John Strachan wrote:
> > On Tuesday 11 July 2006 18:12, John W. Linville wrote:
> >> On Tue, Jul 11, 2006 at 10:32:43AM -0600, Joseph Michael Smidt wrote:
> >>> Will 2.6.18 or 2.6.19 support Intel Wireless 3945ABG?  Please cc me
> >>> since I am not subscribed.   Thanks.
> >>
> >> It will not be in 2.6.18.  Making 2.6.19 is not out of the question,
> >> but it may take some work.
> >
> > Has some agreement been met regarding the mandatory use of the binary
> > regulatory daemon? The webpage seems to suggest it is still necessary,
> > and I'm sure that would disqualify merging the driver with Linux proper.
>
> Why not?
> The whole point is running a system that you know you can support for many
> years, even without a vendor support...
> And to have a system that you know exactly what running in it...
> Having a binary closed source violate this.
>
> Also there is no good reason why supplying this daemon as closed source...
> All they wish is people don't mess with their frequencies, and sooner or
> later someone will...

Don't misinterpret me, that's exactly my feeling too. Ignoring the politics 
and questionable legality entirely, as a matter of practicality, when Intel 
inevitably abandon these cards 5 years from now and their daemon rots, will I 
still be able to use my wireless card? I think not.

Also, I can't see any reason why a mini-pci version of this couldn't work in a 
system other than x86/x86-64, even if Intel don't design such machines.

In my view, it would be unacceptable to merge.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Will there be Intel Wireless 3945ABG support?

[Alan Cox]

Ar Maw, 2006-07-11 am 21:25 +0300, ysgrifennodd Alon Bar-Lev:
> And to have a system that you know exactly what running in it...
> Having a binary closed source violate this.

Also if the binary only chunk of code is neccessary to make the open
source bit work then its a derivative work as I understand the
situation, which makes it all rather questionable from a licensing
perspsective.

Hopefully Intel will find a sensible solution to the problem or someone
will just reverse engineer it away.

Alan

Re: Will there be Intel Wireless 3945ABG support?

[Matthieu CASTET]

Le Tue, 11 Jul 2006 19:55:19 +0100, Alan Cox a écrit :

> Ar Maw, 2006-07-11 am 21:25 +0300, ysgrifennodd Alon Bar-Lev:
>> And to have a system that you know exactly what running in it...
>> Having a binary closed source violate this.
> 
> Also if the binary only chunk of code is neccessary to make the open
> source bit work then its a derivative work as I understand the
> situation, which makes it all rather questionable from a licensing
> perspsective.
> 
> Hopefully Intel will find a sensible solution to the problem or someone
> will just reverse engineer it away.
> 
Well openbsd guys already reversed engineer it :
http://kerneltrap.org/node/6650

Re: Will there be Intel Wireless 3945ABG support?

[Daniel Bonekeeper]

On 7/11/06, Matthieu CASTET <castet.matthieu@free.fr> wrote:
> Le Tue, 11 Jul 2006 19:55:19 +0100, Alan Cox a écrit:
>
> > Ar Maw, 2006-07-11 am 21:25 +0300, ysgrifennodd Alon Bar-Lev:
> >> And to have a system that you know exactly what running in it...
> >> Having a binary closed source violate this.
> >
> > Also if the binary only chunk of code is neccessary to make the open
> > source bit work then its a derivative work as I understand the
> > situation, which makes it all rather questionable from a licensing
> > perspsective.
> >
> > Hopefully Intel will find a sensible solution to the problem or someone
> > will just reverse engineer it away.
> >
> Well openbsd guys already reversed engineer it :
> http://kerneltrap.org/node/6650

[quote]

Porting wpi

When asked the likelihood that the wpi driver would be ported to
Linux, Damien thought that this was unlikely. "I doubt the Linux
community will ever leverage this work since Intel is developing a
802.11 layer for the Linux kernel," he said, "Linux kernel developers
probably can't afford to upset Intel."

[/quote]

Huh ?

-- 
What this world needs is a good five-dollar plasma weapon.

Re: Will there be Intel Wireless 3945ABG support?

[Matthew Garrett]

On Tue, Jul 11, 2006 at 07:55:19PM +0100, Alan Cox wrote:

> Hopefully Intel will find a sensible solution to the problem or someone
> will just reverse engineer it away.

The ipw3945_daemon.h file includes a pretty full description of what the 
daemon has to do, and all the structures have nice friendly names. 
There's also a changelog of the protocol. It shouldn't take someone 
long.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Will there be Intel Wireless 3945ABG support?

[H. Peter Anvin]

Matthew Garrett wrote:
> On Tue, Jul 11, 2006 at 07:55:19PM +0100, Alan Cox wrote:
> 
>> Hopefully Intel will find a sensible solution to the problem or someone
>> will just reverse engineer it away.
> 
> The ipw3945_daemon.h file includes a pretty full description of what the 
> daemon has to do, and all the structures have nice friendly names. 
> There's also a changelog of the protocol. It shouldn't take someone 
> long.
> 

It's already been done, too.

	-hpa

Re: Will there be Intel Wireless 3945ABG support?

[Matthew Garrett]

On Tue, Jul 11, 2006 at 04:54:24PM -0700, H. Peter Anvin wrote:
> Matthew Garrett wrote:
> >The ipw3945_daemon.h file includes a pretty full description of what the 
> >daemon has to do, and all the structures have nice friendly names. 
> >There's also a changelog of the protocol. It shouldn't take someone 
> >long.
> >
> 
> It's already been done, too.

For Linux, too? The OpenBSD approach seems to have been to integrate it 
into the driver, which is fine for them but would probably make it more 
awkward for us to keep things synced with the Intel code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Will there be Intel Wireless 3945ABG support?

[James Ketrenos]

Alan Cox wrote:
> Ar Maw, 2006-07-11 am 21:25 +0300, ysgrifennodd Alon Bar-Lev:
>> And to have a system that you know exactly what running in it...
>> Having a binary closed source violate this.
> 
> Also if the binary only chunk of code is neccessary to make the open
> source bit work then its a derivative work as I understand the
> situation, 

Following that logic one must draw the conclusion that the firmware that
runs on a scsi controller is derived from the driver provided with the
kernel that communicates with it.

The obvious distinction between scsi firmware and the regulatory
daemon blob being discussed here is that the regulatory daemon runs on
the host vs. an adapter.  However, if you consider the communication
interface between the kernel and the user space daemon to be analogous
to the communication interface between the kernel driver and the
firmware that runs on an adapter, then the distinction of running on the
host is irrelevant.

> which makes it all rather questionable from a licensing
> perspsective.

There are no questions from a licensing standpoint.

The regulatory daemon is in no way derived from any GPL work, and the
GPL driver is provided with everything it needs to talk to the
interfaces defined through the ipw3945_daemon.h header file.

> Hopefully Intel will find a sensible solution to the problem or someone
> will just reverse engineer it away.

Invariably someone will make such a piece of code available on Linux.

To that end I would encourage anyone that may be interested in using
such a piece of code to read the regulatory notice packaged with our
drivers, and linked for your reference here[1].

James

1.  http://bughost.org/ipw3945/NOTICE

> 
> Alan

Re: Will there be Intel Wireless 3945ABG support?

[David Miller]

From: James Ketrenos <jketreno@linux.intel.com>
Date: Tue, 11 Jul 2006 17:35:48 -0700

> The obvious distinction between scsi firmware and the regulatory
> daemon blob being discussed here is that the regulatory daemon runs
> on the host vs. an adapter.  However, if you consider the
> communication interface between the kernel and the user space daemon
> to be analogous to the communication interface between the kernel
> driver and the firmware that runs on an adapter, then the
> distinction of running on the host is irrelevant.

The core issue is whether the userland blob could stand alone and is
something that could exist independant of Linux and the kernel side
GPL'd driver.

Difficult areas arise when you design a set of interfaces specifically
to talk to the binary blob, and which exist for no other purpose and
do not provide some well defined "standard" API such as the SCSI
command set, as an example.  It is just a backdoor into the binary
blob, and therefore this could make it more likely to be considered
a derivative work.

Firmware that runs on the card is also a tricky area, and not everyone
agrees on that issue as well.

Unfortunately, none of this is fun stuff :-/

Re: Will there be Intel Wireless 3945ABG support?

[Alan Cox]

Ar Maw, 2006-07-11 am 17:35 -0700, ysgrifennodd James Ketrenos:
> The obvious distinction between scsi firmware and the regulatory
> daemon blob being discussed here is that the regulatory daemon runs on
> the host vs. an adapter.  

"It isn't a pirate copy of the movie because my copy is on VHS and
theirs is on DVD"

Derivative works are not really a question of where something is, think
about a distributed computation, or a tool which partly compiles a
program into VHDL for high performance execution.

I'm not sure this is a useful kernel list argument anyway since I am
sure Intel legal will have considered the question and reached their own
conclusions and also vendors and Intel will continue beating each other
up until a neat solution is found.

> There are no questions from a licensing standpoint.

For Intel sure, if it owns all the bits then it can do what it likes
with its bits.


> To that end I would encourage anyone that may be interested in using
> such a piece of code to read the regulatory notice packaged with our
> drivers, and linked for your reference here[1].

Oh I understand *why* the issue arises, and as a licensed radio amateur
I'm quite well aware of the concerns. I'm also permitted to use 2.4Ghz
at higher power for amateur purposes.

Alan

Re: Will there be Intel Wireless 3945ABG support?

[Alon Bar-Lev]

On 7/12/06, James Ketrenos <jketreno@linux.intel.com> wrote:
> The regulatory daemon is in no way derived from any GPL work, and the
> GPL driver is provided with everything it needs to talk to the
> interfaces defined through the ipw3945_daemon.h header file.

You are kidding, right?!?!
If you cannot operate the device using GPLed software!

What use is that software if after using all the GPLed available
drivers for the device it still does not work, and need a properiteary
modules in order to complete it? The derived work is taking something
that *WORKS* and making some modifications... In this case you don't
even have something that *WORKS*.

Best Regards,
Alon Bar-Lev.

RE: Will there be Intel Wireless 3945ABG support?

[David Schwartz]

> Also if the binary only chunk of code is neccessary to make the open
> source bit work then its a derivative work as I understand the
> situation,

	The issue is not whether the userspace daemon is a derivative work of any
GPL'd work and therefore must be covered. The issue is whether the kernel
driver and the userspace program are one work or two. If neither is any use
without the other, and the two were designed together, it seems implausible
to argue that they are two works.

	A boundary that consists of an API that allows the work on either side to
be interchanged with others and the other work still operate substantially
the same can certainly divide two works. That's why a C program that uses
the standard library can be a separate work from the standard library. Any C
program works with that library, and the library works with any C program.

	A boundary custom designed for these two programs, and which is not
intended to allow either program to be replaced with another, would not seem
to do the job.

	DS

Re: Will there be Intel Wireless 3945ABG support?

[Thorsten Kranzkowski]

On Tue, Jul 11, 2006 at 09:25:45PM +0300, Alon Bar-Lev wrote:
> 
> Also there is no good reason why supplying this daemon as closed source... 
> All they
> wish is people don't mess with their frequencies, and sooner or later 
> someone will...

Using interesting frequencies or output power would be fun for
radio amateurs (like me). 2.4GHz is one of our playgrounds after all :-)

Just because Joe Average isn't allowed to use such features doesn't
mean that there aren't any legitimate users for it.
 
Preventing the accidental use of unauthorized features would be enough, 
I think (warnings that force you to look up the manual to find out the
correct --force option or similar)
I expect developers to be sensible enough to only offer 'public legal'
values in the default options list.

just my 2 cents,
Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Re: Will there be Intel Wireless 3945ABG support?

[Thomas Tuttle]

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

On July 11 at 16:16 EDT, Thorsten Kranzkowski hastily scribbled:
> On Tue, Jul 11, 2006 at 09:25:45PM +0300, Alon Bar-Lev wrote:
> > 
> > Also there is no good reason why supplying this daemon as closed source... 
> > All they
> > wish is people don't mess with their frequencies, and sooner or later 
> > someone will...
> 
> Using interesting frequencies or output power would be fun for
> radio amateurs (like me). 2.4GHz is one of our playgrounds after all :-)

Hear, hear!

> Just because Joe Average isn't allowed to use such features doesn't
> mean that there aren't any legitimate users for it.
>  
> Preventing the accidental use of unauthorized features would be enough, 
> I think (warnings that force you to look up the manual to find out the
> correct --force option or similar)
> I expect developers to be sensible enough to only offer 'public legal'
> values in the default options list.

Frankly, I think Intel is misinterpreting how strict the FCC is being
(or maybe the FCC is being too strict).  I would interpret their
mandates as meaning that, as purchased, equipment can't transmit on
unauthorized frequencies, and that it's not "user-modifiable".  User
modification doesn't include things like opening the case of a toy
walkie-talkie up and swapping out a crystal, nor does it include things
like opening up the firmware or driver for something and messing with
it.

Frankly, I'm annoyed that, if Intel understood the full extent of the
problem, that they didn't take a better approach and simply give the
card a set of legal values.  It doesn't need to understand the
subtleties of what they mean.  It just needs to know frequencies 1, 2,
and 3 are okay, but not 4, 5, and 6, and that the max power is xx dBm.

OTOH, I'd love to get one of these cards and play with it.  I'd love a
WiFi card that can run up to 5 or 10 watts.  (1500 is a little much, and
my laptop's battery can't supply it :-)

-- Thomas Tuttle

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

Re: Will there be Intel Wireless 3945ABG support?

[H. Peter Anvin]

Thomas Tuttle wrote:
> 
> Frankly, I think Intel is misinterpreting how strict the FCC is being
> (or maybe the FCC is being too strict).  I would interpret their
> mandates as meaning that, as purchased, equipment can't transmit on
> unauthorized frequencies, and that it's not "user-modifiable".  User
> modification doesn't include things like opening the case of a toy
> walkie-talkie up and swapping out a crystal, nor does it include things
> like opening up the firmware or driver for something and messing with
> it.
> 

Unfortunately you're wrong.  Some manufacturers have gotten rapped for 
marketing equipment that can be modded by stuff like desoldering diodes.

The FCC has some incredibly heavy-weight regulations, like:

- Problem: unlicensed high-power CB operation
- Solution: ban amplifiers that work anywhere near the CB band, 
including several amateur radio bands (even for sale to users with valid 
amateur licenses)

- Problem: unencrypted cell phones
- Solutions: ban scanners that work on the cell phone bands

... etc ...

	-hpa

Re: Will there be Intel Wireless 3945ABG support?

[David Miller]

From: Thomas Tuttle <thinkinginbinary@gmail.com>
Date: Tue, 11 Jul 2006 20:42:12 -0400

> Frankly, I'm annoyed that, if Intel understood the full extent of the
> problem, that they didn't take a better approach and simply give the
> card a set of legal values.  It doesn't need to understand the
> subtleties of what they mean.  It just needs to know frequencies 1, 2,
> and 3 are okay, but not 4, 5, and 6, and that the max power is xx dBm.

You miss many important issues in your diatribe.  I don't like the
situation either, but I hold this position understanding the
conditions (both technical and legal) under which companies such as
Atheros and Intel must operate.

First off, the reason these radios are fully programmable, not fixed
in on-board firmware or likewise, is so that people doing "special
stuff" outside the normal operating frequencies and power levels, and
have a license to do so, can use these wireless chips out of the box.
Otherwise custom boards would need to be produced and that is
prohibitively expensive and restrictive for what some of these
folks want to do.

Such companies can thus provide firmware or drivers that operate
within a customer's specially licensed frequency or power range once
that customer proves they do indeed have a license from the FCC to use
it.

Secondarily, it is up to lawyers, not you, to decide what is a safe
manner for the maker of a wireless chipset to abide by the FCC
regulations.  And across the board, lawyers representing these
companies and other entities seem to agree that providing the full
source code to a wireless chip driver's radio programming makes
it "user-modifiable", whereas hiding the radio programming behind
a binary-only blob or firmware satisfies the FCC requirements.

And if you think they haven't invested any effort to look into
alternatives that will satisfy both the FCC and the open source crowd,
think again.  You can be sure they've spent a lot of time thinking
about how to deal with this.  It is absurd to say things which suggest
that these guys are sitting around twiddling their thumbs about the
issue, and think the current state of affairs is ok.

It's not a matter of "impossible" vs. "possible" to modify the
frequencies and power levels outside of the allowed range, rather it's
a matter of making it "difficult enough" for an end user to modify
these restrictions.

As long as it's Intel's or Atheros's ass that gets reamed by the FCC
for running afoul of the radio frequency regulations, they will not be
posting the source code to program their radios.  On the other hand,
if it happens to get legally reverse engineered, then unless these
companies assisted in that reverse engineering effort, the FCC really
couldn't go after them.  Such companies would also not be able to
participate in maintainence of a driver for their chips containing
the reverse engineered components.  However, we've dealt with that
kind of situation just fine in the past :)

So we will be in this endless loop finding ways to legally reverse
engineer binary blobs to get fully free wireless drivers, until the
FCC regulation situation is rectified.

Re: Will there be Intel Wireless 3945ABG support?

[Valdis.Kletnieks]

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

On Tue, 11 Jul 2006 20:42:12 EDT, Thomas Tuttle said:

> Frankly, I think Intel is misinterpreting how strict the FCC is being
> (or maybe the FCC is being too strict).

The FCC has in the past managed to come up with the most astoundingly
brain-dead regulations (for instance, "fixing" the lack of any actual
encryption on some cell and portable phone by banning scanners...)

> Frankly, I'm annoyed that, if Intel understood the full extent of the
> problem, that they didn't take a better approach and simply give the
> card a set of legal values.  It doesn't need to understand the
> subtleties of what they mean.  It just needs to know frequencies 1, 2,
> and 3 are okay, but not 4, 5, and 6, and that the max power is xx dBm.

The problem is that in the US, 1,2, and 3 are OK, in Sweden 1,4,6 are OK,
in Germany it's 2,3, and 7, and China insists on 1.5,2.5, and 3.5....


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

Re: Will there be Intel Wireless 3945ABG support?

[Alistair John Strachan]

On Wednesday 12 July 2006 01:42, Thomas Tuttle wrote:
> On July 11 at 16:16 EDT, Thorsten Kranzkowski hastily scribbled:
> > On Tue, Jul 11, 2006 at 09:25:45PM +0300, Alon Bar-Lev wrote:
> > > Also there is no good reason why supplying this daemon as closed
> > > source... All they
> > > wish is people don't mess with their frequencies, and sooner or later
> > > someone will...
> >
> > Using interesting frequencies or output power would be fun for
> > radio amateurs (like me). 2.4GHz is one of our playgrounds after all :-)
>
> Hear, hear!
>
> > Just because Joe Average isn't allowed to use such features doesn't
> > mean that there aren't any legitimate users for it.
> >
> > Preventing the accidental use of unauthorized features would be enough,
> > I think (warnings that force you to look up the manual to find out the
> > correct --force option or similar)
> > I expect developers to be sensible enough to only offer 'public legal'
> > values in the default options list.
>
> Frankly, I think Intel is misinterpreting how strict the FCC is being
> (or maybe the FCC is being too strict).  I would interpret their
> mandates as meaning that, as purchased, equipment can't transmit on
> unauthorized frequencies, and that it's not "user-modifiable".  User
> modification doesn't include things like opening the case of a toy
> walkie-talkie up and swapping out a crystal, nor does it include things
> like opening up the firmware or driver for something and messing with
> it.

If you give Matthieu's link[1] a quick read, the OpenBSD developer that 
reverse engineered the regulatory blob seems to indicate that the FCC 
regulations are just an excuse, so Intel can hide their IP inside the blob.

I'm not sure to what extent this is accurate, but it would seem that you would 
leave the driver functionally impaired if you simply removed the regulatory 
checks.

[1] http://kerneltrap.org/node/6650

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Will there be Intel Wireless 3945ABG support?

[Alistair John Strachan]

On Wednesday 12 July 2006 09:19, Alistair John Strachan wrote:
> On Wednesday 12 July 2006 01:42, Thomas Tuttle wrote:
> > On July 11 at 16:16 EDT, Thorsten Kranzkowski hastily scribbled:
> > > On Tue, Jul 11, 2006 at 09:25:45PM +0300, Alon Bar-Lev wrote:
> > > > Also there is no good reason why supplying this daemon as closed
> > > > source... All they
> > > > wish is people don't mess with their frequencies, and sooner or later
> > > > someone will...
> > >
> > > Using interesting frequencies or output power would be fun for
> > > radio amateurs (like me). 2.4GHz is one of our playgrounds after all
> > > :-)
> >
> > Hear, hear!
> >
> > > Just because Joe Average isn't allowed to use such features doesn't
> > > mean that there aren't any legitimate users for it.
> > >
> > > Preventing the accidental use of unauthorized features would be enough,
> > > I think (warnings that force you to look up the manual to find out the
> > > correct --force option or similar)
> > > I expect developers to be sensible enough to only offer 'public legal'
> > > values in the default options list.
> >
> > Frankly, I think Intel is misinterpreting how strict the FCC is being
> > (or maybe the FCC is being too strict).  I would interpret their
> > mandates as meaning that, as purchased, equipment can't transmit on
> > unauthorized frequencies, and that it's not "user-modifiable".  User
> > modification doesn't include things like opening the case of a toy
> > walkie-talkie up and swapping out a crystal, nor does it include things
> > like opening up the firmware or driver for something and messing with
> > it.
>
> If you give Matthieu's link[1] a quick read, the OpenBSD developer that
> reverse engineered the regulatory blob seems to indicate that the FCC
> regulations are just an excuse, so Intel can hide their IP inside the blob.

Sorry, correction, reverse engineered the interface between the blob and 
driver, not the regulatory blob itself.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.