wireless-regdb: flaw in general functionality

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).

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.

Quoted 4 lines · Luis R. Rodriguez

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:

Quoted 5 lines

-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?

Quoted 10 lines · Pavel Roskin

Quoted 7 lines · Luis R. Rodriguez

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

Quoted 5 lines

Quoted 3 lines

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

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?

Quoted 6 lines · Richard Farina

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

Quoted 3 lines · Luis R. Rodriguez

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.

Quoted 10 lines · Pavel Roskin

Quoted 4 lines · Luis R. Rodriguez

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.

Quoted 4 lines

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

Quoted 40 lines · Luis R. Rodriguez

Quoted 10 lines · Pavel Roskin

Quoted 4 lines · Luis R. Rodriguez

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.

Quoted 10 lines

Quoted 4 lines

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.

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

Hi.

Quoted 2 lines · Luis R. Rodriguez

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?

Quoted 4 lines

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.

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

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

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

Quoted 2 lines

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

Is that still current?

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?