wireless-regdb: flaw in general functionality

wireless-regdb: flaw in general functionality

[Richard Farina]

First of all I would like to say that the entire idea and function 
behind crda is vastly improved from the old regulatory settings hard 
coded in the kernel.  In light of this, however, we all seem to be 
avoiding a very clear part of reality.

crda and the regulatory database restrain the channels that a person can 
legally transmit on based on their (presumed) current regulatory 
legislation.  Unfortunately, when I learned about radios I was taught 
that radios can RECEIVE as well as transmit.  In fact, in the USA (the 
country I live in and hence where I am most familiar with the laws) it 
is 100% legal to monitor any frequency that you desire.  crda clearly 
misses that fact and doesn't permit proper legal operation of the radio 
device.

crda and the regulatory database should be modified so that I can use my 
cards in the legal manner prescribed by the FCC (my regulatory body here 
in the USA).

Thanks,
Rick Farina

PS> those of you that are warming up to tell me "it's not legal to 
monitor cell phones" please save the key strokes.  It is not legal to 
modify, buy, sell or create a device that can monitor cell phones, if 
you already own one then it is legal to use, as it always has been and 
always will be. (FYI I've not found a device yet that can hit the cell 
phone bands.) Long ago it was promised that the FCC would never make 
listening against the law, surprisingly they have kept their promise so far.

Re: wireless-regdb: flaw in general functionality

[Luis R. Rodriguez]

On Mon, Nov 24, 2008 at 02:32:20PM -0800, Richard Farina wrote:
> First of all I would like to say that the entire idea and function
> behind crda is vastly improved from the old regulatory settings hard
> coded in the kernel.  In light of this, however, we all seem to be
> avoiding a very clear part of reality.
> 
> crda and the regulatory database restrain the channels that a person can
> legally transmit on based on their (presumed) current regulatory
> legislation.  Unfortunately, when I learned about radios I was taught
> that radios can RECEIVE as well as transmit.  In fact, in the USA (the
> country I live in and hence where I am most familiar with the laws) it
> is 100% legal to monitor any frequency that you desire.  crda clearly
> misses that fact and doesn't permit proper legal operation of the radio
> device.
> 
> crda and the regulatory database should be modified so that I can use my
> cards in the legal manner prescribed by the FCC (my regulatory body here
> in the USA).

The reguluatory database is designed with 802.11 in mind, its database
also provides enablement on frequency, not disablement. By default
cfg80211 disallows everything except what is listed for the current
regulatory domain being used.

Your point about not being able to listen is a good one, and a patch to
update the the US in consideration of part 15 rules would be
appreciated. Keep in mind we have flags for such things:

  -Passive scan
  -No-IBSS

We should probably rename no-ibss to no-beaconing though as that is the
real meaning inention behind it. 

  Luis

Re: wireless-regdb: flaw in general functionality

[Pavel Roskin]

On Mon, 2008-11-24 at 15:12 -0800, Luis R. Rodriguez wrote:

> Your point about not being able to listen is a good one, and a patch to
> update the the US in consideration of part 15 rules would be
> appreciated. Keep in mind we have flags for such things:
> 
>   -Passive scan
>   -No-IBSS
> 
> We should probably rename no-ibss to no-beaconing though as that is the
> real meaning inention behind it. 

Maybe you mean no-transmit?  I don't think seeing an AP transmitting on
a wrong frequency is an excuse for doing the same.  At least in some
jurisdictions.

-- 
Regards,
Pavel Roskin

Re: wireless-regdb: flaw in general functionality

[Luis R. Rodriguez]

On Mon, Nov 24, 2008 at 3:21 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Mon, 2008-11-24 at 15:12 -0800, Luis R. Rodriguez wrote:
>
>> Your point about not being able to listen is a good one, and a patch to
>> update the the US in consideration of part 15 rules would be
>> appreciated. Keep in mind we have flags for such things:
>>
>>   -Passive scan
>>   -No-IBSS
>>
>> We should probably rename no-ibss to no-beaconing though as that is the
>> real meaning inention behind it.
>
> Maybe you mean no-transmit?

Yeah sure, that seems to make more sense.

 Luis

Re: wireless-regdb: flaw in general functionality

[Richard Farina]

Luis R. Rodriguez wrote:
> On Mon, Nov 24, 2008 at 3:21 PM, Pavel Roskin <proski@gnu.org> wrote:
>   
>> On Mon, 2008-11-24 at 15:12 -0800, Luis R. Rodriguez wrote:
>>
>>     
>>> Your point about not being able to listen is a good one, and a patch to
>>> update the the US in consideration of part 15 rules would be
>>> appreciated. Keep in mind we have flags for such things:
>>>
>>>   -Passive scan
>>>   -No-IBSS
>>>
>>> We should probably rename no-ibss to no-beaconing though as that is the
>>> real meaning inention behind it.
>>>       
>> Maybe you mean no-transmit?
>>     
>
> Yeah sure, that seems to make more sense.
>
>   
I'm all for adding it to crda as no-transmit but, is that a valid flag?  
Also, how well does it work?  From a monitor mode interface you can 
inject raw packets out of the interface.  Would just adding 
"no-transmit" into the crda line work?  I certainly don't see this in 
the crda code anywhere, nor in the definition of regdb file.  I presume 
this has to be added?

Thanks,
Rick Farina




>  Luis
>
>   

Re: wireless-regdb: flaw in general functionality

[Pavel Roskin]

On Mon, 2008-11-24 at 21:26 -0500, Richard Farina wrote:

> I'm all for adding it to crda as no-transmit but, is that a valid flag?  
> Also, how well does it work?  From a monitor mode interface you can 
> inject raw packets out of the interface.  Would just adding 
> "no-transmit" into the crda line work?  I certainly don't see this in 
> the crda code anywhere, nor in the definition of regdb file.  I presume 
> this has to be added?

I don't know anything about the process for introducing new CRDA flags.
If it's hard to do, maybe the transmit power could be set to 0?

-- 
Regards,
Pavel Roskin

Re: wireless-regdb: flaw in general functionality

[Luis R. Rodriguez]

On Mon, Nov 24, 2008 at 06:31:39PM -0800, Pavel Roskin wrote:
> On Mon, 2008-11-24 at 21:26 -0500, Richard Farina wrote:
> 
> > I'm all for adding it to crda as no-transmit but, is that a valid flag?
> > Also, how well does it work?  From a monitor mode interface you can
> > inject raw packets out of the interface.  Would just adding
> > "no-transmit" into the crda line work?  I certainly don't see this in
> > the crda code anywhere, nor in the definition of regdb file.  I presume
> > this has to be added?
> 
> I don't know anything about the process for introducing new CRDA flags.

This is documented here:

http://wireless.kernel.org/en/developers/Regulatory#Changingthedatabasefileformat

  Luis

Re: wireless-regdb: flaw in general functionality

[Pavel Roskin]

On Tue, 2008-11-25 at 16:19 -0800, Luis R. Rodriguez wrote:

> This is documented here:
> 
> http://wireless.kernel.org/en/developers/Regulatory#Changingthedatabasefileformat

I mean, I don't know how painful it can be.  Perhaps it's better to
anticipate some requirements earlier than to change them later.  I think
both "don't transmit" and "don't transmit unless permitted by the AP"
could be useful in some jurisdictions.

-- 
Regards,
Pavel Roskin

Re: wireless-regdb: flaw in general functionality

[Luis R. Rodriguez]

On Tue, Nov 25, 2008 at 04:35:54PM -0800, Pavel Roskin wrote:
> On Tue, 2008-11-25 at 16:19 -0800, Luis R. Rodriguez wrote:
> 
> > This is documented here:
> >
> > http://wireless.kernel.org/en/developers/Regulatory#Changingthedatabasefileformat
> 
> I mean, I don't know how painful it can be.  Perhaps it's better to
> anticipate some requirements earlier than to change them later.

Its painful to add anything new. To understand this better it helps to
understand why some flags were added in the first place to regulatory rules.
The short and sweet answer is DFS. And the general rule of thumb goes like this:

When in a DFS freq, if you don't support DFS in your mode of operation,
then you cannot TX.

So if you don't support DFS in IBSS, you get NO-IBSS. If your AP doesn't
support DFS then you can't use DFS channels. If you don't support DFS
then you better not use active scanning on a STA, hence the passive scan
flag (I guess this should be renamed to NO-ACTIVE-SCAN to be more
consistent).

The NO-HT20 is historical, we're not aware of countries disallowing
this. No-HT40 is also a bit historical as it seems the countries which
do not allow this will soon allow for it.

The NO-OFDM and NO-CCK flag is unused and purely historical.

So before adding a flag I think its *really* good to think about it
thrice and see if there is a need of it, otherwise the answer should
usually be that its not a good idea to add it.

If anything we can consolidate flags or remove flags, that would be nicer
if possible.

> I think
> both "don't transmit" and "don't transmit unless permitted by the AP"
> could be useful in some jurisdictions.

Don't transmit is implicit, CRDA just "allows", so the flags we have now
are all negative for special considerations on "allowing", such as NO
IBSS, etc.

  Luis

Re: wireless-regdb: flaw in general functionality

[Richard Farina]

Luis R. Rodriguez wrote:
> On Tue, Nov 25, 2008 at 04:35:54PM -0800, Pavel Roskin wrote:
>   
>> On Tue, 2008-11-25 at 16:19 -0800, Luis R. Rodriguez wrote:
>>
>>     
>>> This is documented here:
>>>
>>> http://wireless.kernel.org/en/developers/Regulatory#Changingthedatabasefileformat
>>>       
>> I mean, I don't know how painful it can be.  Perhaps it's better to
>> anticipate some requirements earlier than to change them later.
>>     
>
> Its painful to add anything new. To understand this better it helps to
> understand why some flags were added in the first place to regulatory rules.
> The short and sweet answer is DFS. And the general rule of thumb goes like this:
>
> When in a DFS freq, if you don't support DFS in your mode of operation,
> then you cannot TX.
>
> So if you don't support DFS in IBSS, you get NO-IBSS. If your AP doesn't
> support DFS then you can't use DFS channels. If you don't support DFS
> then you better not use active scanning on a STA, hence the passive scan
> flag (I guess this should be renamed to NO-ACTIVE-SCAN to be more
> consistent).
>
> The NO-HT20 is historical, we're not aware of countries disallowing
> this. No-HT40 is also a bit historical as it seems the countries which
> do not allow this will soon allow for it.
>
> The NO-OFDM and NO-CCK flag is unused and purely historical.
>
> So before adding a flag I think its *really* good to think about it
> thrice and see if there is a need of it, otherwise the answer should
> usually be that its not a good idea to add it.
>
> If anything we can consolidate flags or remove flags, that would be nicer
> if possible.
>
>   
>> I think
>> both "don't transmit" and "don't transmit unless permitted by the AP"
>> could be useful in some jurisdictions.
>>     
>
> Don't transmit is implicit, CRDA just "allows", so the flags we have now
> are all negative for special considerations on "allowing", such as NO
> IBSS, etc.
>
>   
This is simply not the case.  Implicit is don't tune the radio, this 
prevents both transmission and reception which needlessly limits useful 
features of a device for no regulatory reason.  This is why we are 
discussing it.

A flag of "no-transmit" is likely accurate in most regulatory domains 
and would allow driver developers to enable more advanced usage of the 
devices (if they choose).  I grant, most users really have no reason for 
this and that is an acceptable reason for someone to refuse to take the 
time to code it.  If someone is willing to take the time to add the 
flag, it should not be turned down as it is both accurate and proper to 
support receive only frequencies.

thanks,
Rick Farina
>   Luis
>
>   

Re: wireless-regdb: flaw in general functionality

[Luis R. Rodriguez]

On Tue, Nov 25, 2008 at 07:10:07PM -0800, Richard Farina wrote:
> Luis R. Rodriguez wrote:
> > On Tue, Nov 25, 2008 at 04:35:54PM -0800, Pavel Roskin wrote:
> >
> >> On Tue, 2008-11-25 at 16:19 -0800, Luis R. Rodriguez wrote:
> >>
> >>
> >>> This is documented here:
> >>>
> >>> http://wireless.kernel.org/en/developers/Regulatory#Changingthedatabasefileformat
> >>>
> >> I mean, I don't know how painful it can be.  Perhaps it's better to
> >> anticipate some requirements earlier than to change them later.
> >>
> >
> > Its painful to add anything new. To understand this better it helps to
> > understand why some flags were added in the first place to regulatory rules.
> > The short and sweet answer is DFS. And the general rule of thumb goes like this:
> >
> > When in a DFS freq, if you don't support DFS in your mode of operation,
> > then you cannot TX.
> >
> > So if you don't support DFS in IBSS, you get NO-IBSS. If your AP doesn't
> > support DFS then you can't use DFS channels. If you don't support DFS
> > then you better not use active scanning on a STA, hence the passive scan
> > flag (I guess this should be renamed to NO-ACTIVE-SCAN to be more
> > consistent).
> >
> > The NO-HT20 is historical, we're not aware of countries disallowing
> > this. No-HT40 is also a bit historical as it seems the countries which
> > do not allow this will soon allow for it.
> >
> > The NO-OFDM and NO-CCK flag is unused and purely historical.
> >
> > So before adding a flag I think its *really* good to think about it
> > thrice and see if there is a need of it, otherwise the answer should
> > usually be that its not a good idea to add it.
> >
> > If anything we can consolidate flags or remove flags, that would be nicer
> > if possible.
> >
> >
> >> I think
> >> both "don't transmit" and "don't transmit unless permitted by the AP"
> >> could be useful in some jurisdictions.
> >>
> >
> > Don't transmit is implicit, CRDA just "allows", so the flags we have now
> > are all negative for special considerations on "allowing", such as NO
> > IBSS, etc.
> >
> >
> This is simply not the case.  Implicit is don't tune the radio, this
> prevents both transmission and reception which needlessly limits useful
> features of a device for no regulatory reason.  This is why we are
> discussing it.
> 
> A flag of "no-transmit" is likely accurate in most regulatory domains
> and would allow driver developers to enable more advanced usage of the
> devices (if they choose).  I grant, most users really have no reason for
> this and that is an acceptable reason for someone to refuse to take the
> time to code it.  If someone is willing to take the time to add the
> flag, it should not be turned down as it is both accurate and proper to
> support receive only frequencies.

Passive scan | NO-IBSS

should suffice. And to be clear NO-IBSS should probably be renamed to
NO-BEACONING.

  Luis

Re: wireless-regdb: flaw in general functionality

[Michael Renzmann]

Hi.

Luis R. Rodriguez wrote:
> When in a DFS freq, if you don't support DFS in your mode of operation,
> then you cannot TX.

Side note: this behaviour is not required in all jurisdictions. German
regulatory body for example allows use of non-DFS-compliant gear even on
(at least some) DFS channels, but only with low TX power. Is that
supported already?

Bye, Mike

Re: wireless-regdb: flaw in general functionality

[Luis R. Rodriguez]

On Tue, Nov 25, 2008 at 09:53:44PM -0800, Michael Renzmann wrote:
> Hi.
> 
> Luis R. Rodriguez wrote:
> > When in a DFS freq, if you don't support DFS in your mode of operation,
> > then you cannot TX.
> 
> Side note: this behaviour is not required in all jurisdictions. German
> regulatory body for example allows use of non-DFS-compliant gear even on
> (at least some) DFS channels, but only with low TX power. Is that
> supported already?

Michael,

I reviewed this internally and there is disagreement on your statement
about German rules. Perhaps there is also a terminology disconnect
between "DFS" and "Radar Detection" and how this applies to a STA or an
AP.

For STA devices "DFS" is required for all Europe regdomains including
Germany for channels 52 to 140 inclusive. "DFS" for STAs means passive
scanning and no adhoc for STA devices (or Mesh, hence NO-BEACONING name
suggestion for the flag).

When on AP and on these channels the AP must do radar detection, in
Germany and rest of Europe and in all other regions. Radar detection
includes a bunch of required functions for APs which we won't get into
on this thread.

Perhaps you are thinking of old interim rules that applies in Germany
and elsewhere. But they no longer apply anyway in Europe.

  Luis

Re: wireless-regdb: flaw in general functionality

[Michael Renzmann]

Hi Luis.

Luis R. Rodriguez wrote:
>> Side note: this behaviour is not required in all jurisdictions. German
>> regulatory body for example allows use of non-DFS-compliant gear even on
>> (at least some) DFS channels, but only with low TX power. Is that
>> supported already?
> I reviewed this internally and there is disagreement on your statement
> about German rules.

Indeed, and that is for a good reason. I have rechecked, and I found that
I have confused TPC and DFS (doh!).

> For STA devices "DFS" is required for all Europe regdomains including
> Germany for channels 52 to 140 inclusive.

Ack.

Plus, if I understand the regulatory rules [1] correctly, channels 36 to
48 don't require DFS in Germany, but may only be used in confined spaces.
However, given that I was wrong with my understanding before, it would be
good if someone else could double-check.

Sorry for any caused confusion.

Bye, Mike

[1] http://www.bundesnetzagentur.de/media/archive/5009.pdf (german
language, )

Re: wireless-regdb: flaw in general functionality

[Johannes Berg]

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

On Wed, 2008-11-26 at 20:55 +0100, Michael Renzmann wrote:

> Plus, if I understand the regulatory rules [1] correctly, channels 36 to

> [1] http://www.bundesnetzagentur.de/media/archive/5009.pdf (german
> language, )

Is that still current? I went through
http://www.bundesnetzagentur.de/media/archive/13358.pdf when I did the
rules for Germany in crda.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless-regdb: flaw in general functionality

[Michael Renzmann]

Hi.

Johannes Berg wrote:
>> [1] http://www.bundesnetzagentur.de/media/archive/5009.pdf (german
>> language, )
> Is that still current?

Afaict yes, at least the information contained in the above file seem to
be similar (although just a very small subset) of the information you
linked to. Yours is more current, however, so if in doubt yours is that
what one should rely on.

Bye, Mike

Re: wireless-regdb: flaw in general functionality

[Johannes Berg]

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

On Wed, 2008-11-26 at 06:53 +0100, Michael Renzmann wrote:

> Side note: this behaviour is not required in all jurisdictions. German
> regulatory body for example allows use of non-DFS-compliant gear even on
> (at least some) DFS channels, but only with low TX power. Is that
> supported already?

Can you point to the relevant frequency plan numbers? I haven't seen
such a thing when reviewing it, but I could well have missed it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]