On Thu, Nov 28, 2024 at 09:08:33AM +0100, Lorenzo Bianconi wrote:
> The channel sets should follow the op_class 131, and the inc should be
> 64 to fit the bandwidth 320MHz.
> diff --git a/src/common/ieee802_11_common.c b/src/common/ieee802_11_common.c
> @@ -2470,7 +2470,7 @@ const struct oper_class_map global_op_class[] = {
> { HOSTAPD_MODE_IEEE80211A, 136, 2, 2, 4, BW20, NO_P2P_SUPP },
>
> /* IEEE P802.11be/D5.0, Table E-4 (Global operating classes) */
> - { HOSTAPD_MODE_IEEE80211A, 137, 31, 191, 32, BW320, NO_P2P_SUPP },
> + { HOSTAPD_MODE_IEEE80211A, 137, 1, 233, 64, BW320, NO_P2P_SUPP },
How has this been tested for the existing STA functionality? Does this
cover the possibility of any two adjacent 160 MHz to be used to form the
320 MHz channel to allow total of six possible center frequencies? With
this min_chan/max_chan/inc values, there would be only four channels
(1, 1+64=65, 1+2*64=129, 1+3*64=193) whereas the possible 320 MHz
channels are defined over the 20 MHz channel number ranges 1..61,
33..93, 65..125, 97..157, 129..189, and 161..221 with channel number of
the center frequency at 31, 63, 95, 127, 159, and 191, respectively.
The current definition generates those six channel numbers of the center
frequencies. If this needs to be changes, there needs to be much more
detailed explanation on why the new values are the best way of encoding
the 320 MHz channels and clarification on how this would work with the
existing uses in wpa_supplicant.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
