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
cesarb@xxxxxxxxxxxxx
_______________________________________________
wireless-regdb mailing list
wireless-regdb@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/wireless-regdb
