| Message ID | 20220901232734.5488-1-cesarb@cesarb.eti.br (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | wireless-regdb: Update regulatory rules for Brazil (BR) | expand |
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.
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)?
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.
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
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)
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 <cesarb@cesarb.eti.br> --- db.txt | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-)