Re: wireless-regdb: flaw in general functionality

[Richard Farina <sidhayn@gmail.com>]

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