Re: wireless-regdb: flaw in general functionality

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

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