The rules for Brazil in wireless-regdb have no comment indicating where
they came from, and haven't been updated in a long time. There have been
some changes to the legislation since then, including the addition of
the 6 GHz and 60 GHz ranges.
Signed-off-by: Cesar Eduardo Barros <[email protected]>
---
db.txt | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/db.txt b/db.txt
index 07cdf4a..c887557 100644
--- a/db.txt
+++ b/db.txt
@@ -279,12 +279,25 @@ country BO: DFS-JP
(5250 - 5330 @ 80), (30), DFS
(5735 - 5835 @ 80), (30)
+# Source:
+# https://www.gov.br/anatel/pt-br/regulado/radiofrequencia/radiacao-restrita
+# https://informacoes.anatel.gov.br/legislacao/resolucoes/2017/936-resolucao-680
+# https://informacoes.anatel.gov.br/legislacao/atos-de-certificacao-de-produtos/2017/1139-ato-14448
country BR: DFS-FCC
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (17), AUTO-BW
- (5250 - 5330 @ 80), (24), DFS, AUTO-BW
- (5490 - 5730 @ 160), (24), DFS
- (5735 - 5835 @ 80), (30)
+ (2400 - 2483.5 @ 40), (30)
+ # The next three ranges have been reduced by 3dB, could be increased
+ # to 30dBm if TPC is implemented.
+ (5150 - 5250 @ 80), (27), NO-OUTDOOR, AUTO-BW
+ (5250 - 5350 @ 80), (27), NO-OUTDOOR, DFS, AUTO-BW
+ # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
+ # Since 5725 ~ 5730 MHz belongs to the next range which has looser
+ # requirements, we can extend the range by 5 MHz to make the kernel
+ # happy and be able to use channel 144.
+ (5470 - 5730 @ 160), (27), DFS
+ (5730 - 5850 @ 80), (30)
+ (5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
+ # EIRP=40dBm (43dBm peak)
+ (57000 - 71000 @ 2160), (40)
country BS: DFS-FCC
(2402 - 2482 @ 40), (20)
--
2.37.2
On Thu, 2022-09-01 at 20:27 -0300, Cesar Eduardo Barros wrote:
>
> + # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
> + # Since 5725 ~ 5730 MHz belongs to the next range which has looser
> + # requirements, we can extend the range by 5 MHz to make the kernel
> + # happy and be able to use channel 144.
> + (5470 - 5730 @ 160), (27), DFS
> + (5730 - 5850 @ 80), (30)
>
If you do the latter as 160 as well, and add AUTO-BW, couldn't you split
them at 5725 correctly? But I guess it doesn't matter anyway.
johannes
Em 02/09/2022 11:53, Johannes Berg escreveu:
> On Thu, 2022-09-01 at 20:27 -0300, Cesar Eduardo Barros wrote:
>>
>> + # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
>> + # Since 5725 ~ 5730 MHz belongs to the next range which has looser
>> + # requirements, we can extend the range by 5 MHz to make the kernel
>> + # happy and be able to use channel 144.
>> + (5470 - 5730 @ 160), (27), DFS
>> + (5730 - 5850 @ 80), (30)
>>
>
> If you do the latter as 160 as well, and add AUTO-BW, couldn't you split
> them at 5725 correctly? But I guess it doesn't matter anyway.
This was copied from the US rules (including the four-line comment),
which have an identical split. If AUTO-BW worked here, I'd expect the US
rules to use it.
--
Cesar Eduardo Barros
[email protected]
On Fri, Sep 02, 2022 at 07:21:50PM -0300, Cesar Eduardo Barros wrote:
> Em 02/09/2022 11:53, Johannes Berg escreveu:
> > On Thu, 2022-09-01 at 20:27 -0300, Cesar Eduardo Barros wrote:
> > >
> > > + # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
> > > + # Since 5725 ~ 5730 MHz belongs to the next range which has looser
> > > + # requirements, we can extend the range by 5 MHz to make the kernel
> > > + # happy and be able to use channel 144.
> > > + (5470 - 5730 @ 160), (27), DFS
> > > + (5730 - 5850 @ 80), (30)
> > >
> >
> > If you do the latter as 160 as well, and add AUTO-BW, couldn't you split
> > them at 5725 correctly? But I guess it doesn't matter anyway.
>
> This was copied from the US rules (including the four-line comment), which
> have an identical split. If AUTO-BW worked here, I'd expect the US rules to
> use it.
AUTO-BW would work, and we have countries using it for this case. Iirc
for some countries we move the split to 5730 because even though
5725-5730 is at a lower power limit the rules allow channel 144 to be
used at the power limit for 5710-5725. For the US though I think it's
just historical -- it was done that way initially, and it isn't
important enough that anyone has cared to change it.
But we do generally try to keep the rules matching the official
documents as much as possible, so for new rules we should split at 5725
and use AUTO-BW as Johannes suggested. Could you send a v2 with that
change?
Thanks,
Seth
Em 07/09/2022 11:52, Seth Forshee escreveu:
> On Fri, Sep 02, 2022 at 07:21:50PM -0300, Cesar Eduardo Barros wrote:
>> Em 02/09/2022 11:53, Johannes Berg escreveu:
>>> On Thu, 2022-09-01 at 20:27 -0300, Cesar Eduardo Barros wrote:
>>>>
>>>> + # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
>>>> + # Since 5725 ~ 5730 MHz belongs to the next range which has looser
>>>> + # requirements, we can extend the range by 5 MHz to make the kernel
>>>> + # happy and be able to use channel 144.
>>>> + (5470 - 5730 @ 160), (27), DFS
>>>> + (5730 - 5850 @ 80), (30)
>>>>
>>>
>>> If you do the latter as 160 as well, and add AUTO-BW, couldn't you split
>>> them at 5725 correctly? But I guess it doesn't matter anyway.
>>
>> This was copied from the US rules (including the four-line comment), which
>> have an identical split. If AUTO-BW worked here, I'd expect the US rules to
>> use it.
>
> AUTO-BW would work, and we have countries using it for this case. Iirc
> for some countries we move the split to 5730 because even though
> 5725-5730 is at a lower power limit the rules allow channel 144 to be
> used at the power limit for 5710-5725. For the US though I think it's
> just historical -- it was done that way initially, and it isn't
> important enough that anyone has cared to change it.
The only country I found in the database that does it that way is IL,
and it has the power limits in the opposite direction (its 5470 - 5725
range has a higher power limit than its 5725 - 5875 range, while for BR
and US it's the former range which has a lower power limit); looking at
other countries, AU does the manual adjustment with a comment like US,
while TW has a 5 MHz overlap on its ranges. So the precedent is not
enough for me to be confident that using the official split together
with AUTO-BW would allow using channel 144 (and the 40 MHz and 80 MHz
channels it's part of).
And the single one which does it using AUTO-BW (IL) doesn't change the
bandwidth of its 5725 - 5875 to 160; is it really necessary to do that
change to the bandwidth (considering also that channel 144 is not part
of a pure 160 MHz channel, it could be used only for 80+80)? What about
the 5150 - 5250 and 5250 - 5350 ranges, do they need also to be changed
to 160 so that the combined 5170 - 5330 160 MHz channel can be used, or
does AUTO-BW allow it even though both ranges are declared as allowing
just 80 MHz channels? What about 80+80 channels?
> But we do generally try to keep the rules matching the official
> documents as much as possible, so for new rules we should split at 5725
> and use AUTO-BW as Johannes suggested. Could you send a v2 with that
> change?
Well, it's not exactly a new rule (the current database already has a
5490 - 5730 @ 160 rule), but we could treat it that way since we're
mostly rewriting them all (and the original didn't say where that came
from).
Since I'm not certain that AUTO-BW will be interpreted as expected,
before doing that change, I'll try to see if I can test it first on my
laptop (by sheer luck, I happen to be using the 5650 - 5730 80 MHz
channel right now, so I'd just have to see if it still connects at 80
MHz, assuming I can somehow convince the kernel to load a modified
file). Or would you prefer me to send the patch first (with or without a
change in the channel bandwidths)?
--
Cesar Eduardo Barros
[email protected]
On Wed, Sep 07, 2022 at 05:02:01PM -0300, Cesar Eduardo Barros wrote:
> Em 07/09/2022 11:52, Seth Forshee escreveu:
> > On Fri, Sep 02, 2022 at 07:21:50PM -0300, Cesar Eduardo Barros wrote:
> > > Em 02/09/2022 11:53, Johannes Berg escreveu:
> > > > On Thu, 2022-09-01 at 20:27 -0300, Cesar Eduardo Barros wrote:
> > > > >
> > > > > + # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
> > > > > + # Since 5725 ~ 5730 MHz belongs to the next range which has looser
> > > > > + # requirements, we can extend the range by 5 MHz to make the kernel
> > > > > + # happy and be able to use channel 144.
> > > > > + (5470 - 5730 @ 160), (27), DFS
> > > > > + (5730 - 5850 @ 80), (30)
> > > > >
> > > >
> > > > If you do the latter as 160 as well, and add AUTO-BW, couldn't you split
> > > > them at 5725 correctly? But I guess it doesn't matter anyway.
> > >
> > > This was copied from the US rules (including the four-line comment), which
> > > have an identical split. If AUTO-BW worked here, I'd expect the US rules to
> > > use it.
> >
> > AUTO-BW would work, and we have countries using it for this case. Iirc
> > for some countries we move the split to 5730 because even though
> > 5725-5730 is at a lower power limit the rules allow channel 144 to be
> > used at the power limit for 5710-5725. For the US though I think it's
> > just historical -- it was done that way initially, and it isn't
> > important enough that anyone has cared to change it.
>
> The only country I found in the database that does it that way is IL, and it
> has the power limits in the opposite direction (its 5470 - 5725 range has a
> higher power limit than its 5725 - 5875 range, while for BR and US it's the
> former range which has a lower power limit); looking at other countries, AU
> does the manual adjustment with a comment like US, while TW has a 5 MHz
> overlap on its ranges. So the precedent is not enough for me to be confident
> that using the official split together with AUTO-BW would allow using
> channel 144 (and the 40 MHz and 80 MHz channels it's part of).
You're right that IL seems to be the only one using it accross channel
144. I'd thought there were others, but apparently not.
> And the single one which does it using AUTO-BW (IL) doesn't change the
> bandwidth of its 5725 - 5875 to 160; is it really necessary to do that
> change to the bandwidth (considering also that channel 144 is not part of a
> pure 160 MHz channel, it could be used only for 80+80)? What about the 5150
> - 5250 and 5250 - 5350 ranges, do they need also to be changed to 160 so
> that the combined 5170 - 5330 160 MHz channel can be used, or does AUTO-BW
> allow it even though both ranges are declared as allowing just 80 MHz
> channels? What about 80+80 channels?
You cannot change the bandwidth for 5725 - 5875 to 160; the kernel will
reject the rule since a 160 MHz channel doesn't fit in the range. The
kernel might still allow a 160 MHz channel though. I haven't looked at
this code in quite some time and it's pretty convoluted, but some of the
code does calculate a max bandwidth based on what will fit when dealing
with AUTO-BW rules.
> > But we do generally try to keep the rules matching the official
> > documents as much as possible, so for new rules we should split at 5725
> > and use AUTO-BW as Johannes suggested. Could you send a v2 with that
> > change?
>
> Well, it's not exactly a new rule (the current database already has a 5490 -
> 5730 @ 160 rule), but we could treat it that way since we're mostly
> rewriting them all (and the original didn't say where that came from).
>
> Since I'm not certain that AUTO-BW will be interpreted as expected, before
> doing that change, I'll try to see if I can test it first on my laptop (by
> sheer luck, I happen to be using the 5650 - 5730 80 MHz channel right now,
> so I'd just have to see if it still connects at 80 MHz, assuming I can
> somehow convince the kernel to load a modified file). Or would you prefer me
> to send the patch first (with or without a change in the channel
> bandwidths)?
I'd be interested in your results, especially if there's any way you
could test at 160 MHz bandwidth since the AUTO-BW code in the kernel is
hard to follow. Getting the kernel to trust the file is the tricky part.
It would probably be easier to convince CRDA to do it if you want to go
that route. Or if you contact me off-list I can provide a signed file
that the kernel will trust -- I'm okay with doing that in this case
since we wouldn't be trying anything which would be in violation of the
regulations.
Thanks,
Seth
Em 09/09/2022 10:20, Seth Forshee escreveu:
> On Wed, Sep 07, 2022 at 05:02:01PM -0300, Cesar Eduardo Barros wrote:
>
>> And the single one which does it using AUTO-BW (IL) doesn't change the
>> bandwidth of its 5725 - 5875 to 160; is it really necessary to do that
>> change to the bandwidth (considering also that channel 144 is not part of a
>> pure 160 MHz channel, it could be used only for 80+80)? What about the 5150
>> - 5250 and 5250 - 5350 ranges, do they need also to be changed to 160 so
>> that the combined 5170 - 5330 160 MHz channel can be used, or does AUTO-BW
>> allow it even though both ranges are declared as allowing just 80 MHz
>> channels? What about 80+80 channels?
>
> You cannot change the bandwidth for 5725 - 5875 to 160; the kernel will
> reject the rule since a 160 MHz channel doesn't fit in the range. The
> kernel might still allow a 160 MHz channel though. I haven't looked at
> this code in quite some time and it's pretty convoluted, but some of the
> code does calculate a max bandwidth based on what will fit when dealing
> with AUTO-BW rules.
I took a quick peek at the kernel code, and I also saw the validation
logic which would reject that 160 MHz rule.
From my quick look, it seems that it would set a NO-160MHZ flag in the
rule, which would then propagate to each 20MHz sub-channel, and probably
would lead to it rejecting the use of the whole as a 160MHz channel; but
there's also the 80+80 mode, which would still be allowed (and I vaguely
recall seeing somewhere that adjacent 80+80 was prefered over 160 for
some reason).
>
>>> But we do generally try to keep the rules matching the official
>>> documents as much as possible, so for new rules we should split at 5725
>>> and use AUTO-BW as Johannes suggested. Could you send a v2 with that
>>> change?
>>
>> Well, it's not exactly a new rule (the current database already has a 5490 -
>> 5730 @ 160 rule), but we could treat it that way since we're mostly
>> rewriting them all (and the original didn't say where that came from).
>>
>> Since I'm not certain that AUTO-BW will be interpreted as expected, before
>> doing that change, I'll try to see if I can test it first on my laptop (by
>> sheer luck, I happen to be using the 5650 - 5730 80 MHz channel right now,
>> so I'd just have to see if it still connects at 80 MHz, assuming I can
>> somehow convince the kernel to load a modified file). Or would you prefer me
>> to send the patch first (with or without a change in the channel
>> bandwidths)?
>
> I'd be interested in your results, especially if there's any way you
> could test at 160 MHz bandwidth since the AUTO-BW code in the kernel is
> hard to follow. Getting the kernel to trust the file is the tricky part.
> It would probably be easier to convince CRDA to do it if you want to go
> that route. Or if you contact me off-list I can provide a signed file
> that the kernel will trust -- I'm okay with doing that in this case
> since we wouldn't be trying anything which would be in violation of the
> regulations.
Unfortunately, I don't have any hardware which can use 160MHz channels;
it's only last month that I upgraded my AP to one which can use 80MHz
channels (which is what led me to looking into all this stuff).
After looking at the kernel code, I'm feeling more confident on the
split at 5725 working; I will send the v2 patch.
--
Cesar Eduardo Barros
[email protected]
On Fri, 2022-09-09 at 19:29 -0300, Cesar Eduardo Barros wrote:
>
> From my quick look, it seems that it would set a NO-160MHZ flag in the
> rule, which would then propagate to each 20MHz sub-channel, and probably
> would lead to it rejecting the use of the whole as a 160MHz channel; but
> there's also the 80+80 mode, which would still be allowed (and I vaguely
> recall seeing somewhere that adjacent 80+80 was prefered over 160 for
> some reason).
Much hardware doesn't support it though. I guess it might be easier to
do separate CCA in that case? Dunno.
Anyway.
> Unfortunately, I don't have any hardware which can use 160MHz channels;
> it's only last month that I upgraded my AP to one which can use 80MHz
> channels (which is what led me to looking into all this stuff).
>
Really what I wanted to say is that you should be able to compile a
kernel with e.g. ARCH=um per the instructions at
https://w1.fi/cgit/hostap/tree/tests/hwsim/vm/README
and then test it all in "userspace" with hwsim in the userspace kernel.
johannes