Search Linux Wireless

Re: [PATCH v2,2/2] wifi: mac80211: Refactor STA CSA parsing flow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Johannes,

I will fix the typos and change all the “IE ” to “Element”. The TODO
for 320 MHz bandwidth is used for internal tests, I’ll remove it, too.
 
We had checked the D4.1, and unfortunately, the additional description
for WBCS Element in D3.2 9.4.2.159 is removed. In other words, D4.1
does not change the definitions of WBCS Element and WBCS Element should
be parsed as VHT operating information regardless of the BSS being VHT,
HE, or EHT.
 
After parsing the WBCS Element, the STA needs to check whether the new
channel fits its capabilities according to the operating mode
(VHT/HE/EHT).
However, the existing flow only checks the VHT capability after the
WBCS Element parsing, which is incorrect when the BSS is HE/EHT or the
band is 6 GHz.
 
In summary, I will refactor the WBCS Element parsing part of this
patch, along with other fixes.

Best,
Michael

On Mon, 2023-11-13 at 11:20 +0100, Johannes Berg wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On Mon, 2023-11-13 at 10:11 +0800, Michael-CY Lee wrote:
> > The Wi-Fi Standard (IEEE 802.11-2020 9.4.2.160) initially specified
> that
> > the Wide Bandwidth Channel Switch (WBCS) IE subfields have same
> definitions
> > as the S1G or VHT Operation Information according to the operating
> band.
> > 
> > However, it did not change the definitions in the amendment for 6
> GHz
> > (IEEE 802.11ax-2021), so the logic remain the same for handling the
> WBCS
> > IE even if there is no VHT mode in 6 GHz.
> > 
> > Now the Wi-Fi Standard draft (IEEE P80211be D3.2 9.4.2.159)
> modifies the
> > defitions, making the WBCS IE subfields follow the definitions of
> S1G,
> 
> type - definitions
> 
> > VHT and HE Operation Information in S1G, 5 GHz and 6 GHz band,
> respectively.
> > 
> > APs in 6 GHz band might use the VHT or HE Operation Information to
> build
> > a WBCS IE according to the Wi-Fi Standard they follow. Originally,
> the STA
> 
> Probably should say "Element" in place of all those "IE" - the spec
> stopped calling them "Information Elements" a long time ago :)
> 
> > just parsed the WBCS IE as VHT Operation Inforamtion, which was
> wrong if
> > the AP was actually build the IE by the HE Operation Information.
> > 
> > To avoid the ambiguity, STA should prefer the op_class in the
> Extended
> > Channel Switch Announcement (ECSA) IE rathen than the WBCS IE. If
> the ECSA
> 
> typo - rather
> 
> > IE is not presented in a channel switch to 6 GHz, the STA should be
> aware
> > of the possible ambiguity when parsing the WBCS IE.
> > 
> > To derive the correct bandwidtin in use, the STA should check the
> 
> typo - bandwidth in
> 
> > +case 4:
> > +/* 320 MHz bandwidth
> > + * TODO channel switch to 320 MHz bandwidth should be indiated
> > + * by Bandwidth Indication IE (IEEE P80211be D3.2 9.4.2.159)
> > + */
> > +he_6ghz_oper->control = IEEE80211_EHT_OPER_CHAN_WIDTH_320MHZ;
> > +break;
> 
> I'm not sure what this TODO was meant to refer to, but I do know that
> D4.1 made some changes here, maybe we should check those? I haven't
> even
> checked what the changes are though.
> 
> In any case, checking with a newer draft and using that would seem
> useful?
> 
> Haven't really read all the other things here yet, this just caught
> my
> eye since I also just heard about D4.1 changes, but I don't have that
> or
> even the old stuff all in my head right now.
> 
> johannes
> 




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux