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.
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
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
On Mon, Nov 24, 2008 at 3:21 PM, Pavel Roskin <[email protected]> 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
Luis R. Rodriguez wrote:
> On Mon, Nov 24, 2008 at 3:21 PM, Pavel Roskin <[email protected]> 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
>
>
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
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
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
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, )
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
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
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
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
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
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
>
>
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
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