For the sake of sanity, I think that the way rules from wireless-regdb
are enforced needs to be changed. An example:
country US:
(5170 - 5250 @ 40), (3, 17)
(5250 - 5330 @ 40), (3, 20), DFS
In this case, you will see that I have removed all of the rules that I
do not intend to cite to lower the complexity of the ruleset.
Take for example, channel 48, center frequency 5240. A standard 20 mhz
mode will work as expected, as well as HT40-, however HT40+ cannot be
set because it would need to cross the rule boundary. Each line of a
regulatory domain section is enforced by itself. Channel 52 has a
similiar problem where 20 and HT40+ work but HT40- will not.
As this specific example includes frequencies in the DFS range, you can
obviously see why no one has noticed this failing before. The obviously
expected result is that if two rules abut and a channel is requested
that stradles them, it should take the most restrictive mix between the
two. For instance, if I set channel 48 in HT40+ mode (and we have DFS
support) the rule would be enforced as (3, 17), DFS; while HT40- would
be enforced as the standard (3, 17).
Does this make sense? Right now each rule line is being treated as an
island, and any adjacent rules are ignored. Due to this narrow field of
vision, the proper way to rewrite the above rule is as follows:
country US:
(5170 - 5260 @ 40), (3, 17)
(5240 - 5330 @ 40), (3, 20), DFS
This of course has it's own obvious problem of allowing people to use 48
HT40+ without DFS or allowing people to use 52 HT40- at 20dBm. Not to
mention what happens if we set channel 50 because it would fall into
both rules as it has a center frequency of 5250. Of course in this
example the point is moot because channel 50 isn't allocated anywhere in
the world but the introductions of 5 and 10mhz channels (which are
allowed in the 802.11j standard) may cause some settings that would span
between multiple rules.
The only proper way to fix this is to change the enforcement to view the
entire regdomain and not just enforce one line at a time. so that we can
use legal settings like 48 HT40+ and 52HT40- (presuming we meet the DFS
requirement). I realize that this is currently completely pointless as
we _in fact_ do not support DFS, but this is going to be a problem and I
would like to see it properly resolved so I can stop writing overlapping
rules (which are at best a HACK and at worst clearly allowing people to
break the law).
Thank you for your consideration.
-Rick Farina
On Mon, Mar 16, 2009 at 07:49:00PM -0400, Richard Farina wrote:
> For the sake of sanity, I think that the way rules from wireless-regdb
> are enforced needs to be changed. An example:
>
> country US:
> (5170 - 5250 @ 40), (3, 17)
> (5250 - 5330 @ 40), (3, 20), DFS
>
> In this case, you will see that I have removed all of the rules that I
> do not intend to cite to lower the complexity of the ruleset.
>
> Take for example, channel 48, center frequency 5240. A standard 20 mhz
> mode will work as expected, as well as HT40-, however HT40+ cannot be
> set because it would need to cross the rule boundary. Each line of a
> regulatory domain section is enforced by itself. Channel 52 has a
> similiar problem where 20 and HT40+ work but HT40- will not.
Channel 48 with HT40+ would not work regardless of the regulatory rules;
(48,52) is not one of the allowed HT40 channel pairs. You can use
(36,40), (44,48), (52,56), and (60,64), but not (40,44), (48,52),
(56,60). This is not really a regulatory limit but restriction stated in
IEEE 802.11n Annex J. And same applies to channel 52 with HT40-.
There may be some other examples where the processing of the ruleset
could be improved, but this particular example does not look like
something that would benefit much from a change here.
> As this specific example includes frequencies in the DFS range, you can
> obviously see why no one has noticed this failing before. The obviously
> expected result is that if two rules abut and a channel is requested
> that stradles them, it should take the most restrictive mix between the
> two. For instance, if I set channel 48 in HT40+ mode (and we have DFS
> support) the rule would be enforced as (3, 17), DFS; while HT40- would
> be enforced as the standard (3, 17).
If the channel pair (48,52) were allowed by IEEE 802.11n and we
supported DFS, yes, I would agree with this. However, neither of those
are the case at the moment (and I don't see the former changing in the
future either).
--
Jouni Malinen PGP id EFC895FA
Jouni Malinen wrote:
> On Mon, Mar 16, 2009 at 07:49:00PM -0400, Richard Farina wrote:
>
>
>> For the sake of sanity, I think that the way rules from wireless-regdb
>> are enforced needs to be changed. An example:
>>
>> country US:
>> (5170 - 5250 @ 40), (3, 17)
>> (5250 - 5330 @ 40), (3, 20), DFS
>>
>> In this case, you will see that I have removed all of the rules that I
>> do not intend to cite to lower the complexity of the ruleset.
>>
>> Take for example, channel 48, center frequency 5240. A standard 20 mhz
>> mode will work as expected, as well as HT40-, however HT40+ cannot be
>> set because it would need to cross the rule boundary. Each line of a
>> regulatory domain section is enforced by itself. Channel 52 has a
>> similiar problem where 20 and HT40+ work but HT40- will not.
>>
>
> Channel 48 with HT40+ would not work regardless of the regulatory rules;
> (48,52) is not one of the allowed HT40 channel pairs. You can use
> (36,40), (44,48), (52,56), and (60,64), but not (40,44), (48,52),
> (56,60). This is not really a regulatory limit but restriction stated in
> IEEE 802.11n Annex J. And same applies to channel 52 with HT40-.
>
> There may be some other examples where the processing of the ruleset
> could be improved, but this particular example does not look like
> something that would benefit much from a change here.
>
>
>> As this specific example includes frequencies in the DFS range, you can
>> obviously see why no one has noticed this failing before. The obviously
>> expected result is that if two rules abut and a channel is requested
>> that stradles them, it should take the most restrictive mix between the
>> two. For instance, if I set channel 48 in HT40+ mode (and we have DFS
>> support) the rule would be enforced as (3, 17), DFS; while HT40- would
>> be enforced as the standard (3, 17).
>>
>
> If the channel pair (48,52) were allowed by IEEE 802.11n and we
> supported DFS, yes, I would agree with this. However, neither of those
> are the case at the moment (and I don't see the former changing in the
> future either).
>
>
Okay, so my example isn't good enough because that specific setup is not
allowed, maybe some later time we can discuss the fact that the rules
really are not enforced as a whole and not argue the semantics of my
specific examples. My eventual goal is to have 1-10,000 in the allowed
rules with a NOTX flag for all the frequencies which are monitor
only...but I suppose for now I'll just use that ugly overlapping
regdomain hack until it starts to bite me. I'm sure overlapping two
rules by 20 mhz couldn't possibly confuse things...
If I have no choice but to write funny rules then so be it, but at least
if I could understand how this is interpreted?
(2402 - 2472 @ 40), (3, 20)
(2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
What rules are applied if I set channel 11 in 10 Mhz mode? Considering
support for using 10 mhz channels is being worked on I'm just kinda
curious. I'm also not 100% sure on the rules but since the way
wireless-regdb/crda currently enforces things will allow you to set
20mhz channels in a 40mhz rule I'm also going to assume that it will
allow 10 and 5 mhz channels to be set too (@40 appears to mean "40 or
less" as far as I understand it).
thanks,
Rick