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
