John W. Linville wrote:
On Sun, Mar 12, 2006 at 04:01:57PM -0800, David Rosky wrote:
(Telecommunications Certification Body).The FCC also maintains
a mechanism whereby certification-related questions can be asked
directly of them and whereby answers to previous questions can be
Can you
On Sun, Mar 12, 2006 at 04:01:57PM -0800, David Rosky wrote:
> (Telecommunications Certification Body).The FCC also maintains
> a mechanism whereby certification-related questions can be asked
> directly of them and whereby answers to previous questions can be
Can you point me at this? What
I also suspect that they only have to make it
difficult for an end user and not a technologist.
The issues here can be complex and there there is often
a lot of mis-information. The above statement is basically
true, but the issue of how compliance is determined is
not always simple.
I am a
Kasper Sandberg wrote:
the binary userspace daemon protects against nothing.
In the technical realm, true. In the legal realm, potentially false.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
On Mon, 2006-02-27 at 17:10 +, Christoph Hellwig wrote:
> On Sun, Feb 26, 2006 at 12:58:02AM +, Alan Cox wrote:
> > On Sad, 2006-02-25 at 08:41 +, Christoph Hellwig wrote:
> > > the regualatory problems are not true.
> >
> > They are although the binary interpretation isn't AFAIK fro
On Mon, 27 Feb 2006 17:10:29 +
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 26, 2006 at 12:58:02AM +, Alan Cox wrote:
> > On Sad, 2006-02-25 at 08:41 +, Christoph Hellwig wrote:
> > > the regualatory problems are not true.
> >
> > They are although the binary interpret
On Sun, Feb 26, 2006 at 12:58:02AM +, Alan Cox wrote:
> On Sad, 2006-02-25 at 08:41 +, 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.
> 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
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 i
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 technolo
On Sad, 2006-02-25 at 08:41 +, 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 reas
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 hardwar
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 lapt
> "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
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 enforc
Maxime Bizon wrote:
On Sat, 2006-02-25 at 16:14 +0100, Jean-Baptiste Note wrote:
Hi,
Obviously Intel doesn't want to manufacture one chipset for each subtle
difference in legislation in each and every country it sells its chips
in : Intel wants flexibility.
As pointed out by Jan, the
On Sat, 2006-02-25 at 16:14 +0100, Jean-Baptiste Note wrote:
Hi,
> Obviously Intel doesn't want to manufacture one chipset for each subtle
> difference in legislation in each and every country it sells its chips
> in : Intel wants flexibility.
As pointed out by Jan, the binary approach does not
>
>This is, not even speaking about roaming your device from one country to
>another. End-users want flexibility too...
>
The end user... Even with the closed-source approach I could run on a
frequency that is legal in XYZ but is not in ABC. (Unless all 13 channels
are the same _all_ over the wo
Hi,
> 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.
Obviously Intel doesn't want to manufacture one chipset for each subtle
difference in legislation in each
>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 m
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.
pgpg8UBeK0L6n.pgp
Description: PGP signature
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 f
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 do
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,
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 bulls
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 transmitte
Hello James,
> The daemon utilizes a sysfs interface exposed by
> the driver in order to communicate with the hardware and configure the
> required regulatory parameters.
This seems to be the same kind of architecture as the one for the N770
(maemo.org). How do you expect to hide anything with th
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,
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 w
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).
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 p
31 matches
Mail list logo
