mbox series

[00/15] wifi: support wider-BW OFDMA and fix puncturing

Message ID 20240129184108.49639-17-johannes@sipsolutions.net (mailing list archive)
Headers show
Series wifi: support wider-BW OFDMA and fix puncturing | expand

Message

Johannes Berg Jan. 29, 2024, 6:34 p.m. UTC
EHT/802.11be introduced both wider-bandwidth OFDMA and puncturing,
and we forgot completely about the former, and misimplemented the
latter due to my wrong arguments.

As mentioned earlier, puncturing really should have been in the
chandef, which this moves it to.

Earlier, the series implements wider bandwidth OFDMA support in
mac80211, which requires tracking the AP channel as part of the
channel context, and then declaring them to be incompatible if
EHT is used on two interfaces (and thus there might be OFDMA) if
the AP bandwidth differs.

As part of the refactoring to more clearly determine both local
and AP mode (HT/VHT/HE/EHT) and channel configuration, this makes
mac80211 a bit more strict:
 - no longer accept channel switch when the mode changes
 - no longer use e.g. VHT if the HT channel inside of it
   occupies the wrong spot (e.g. center 40 MHz inside 80 MHz)
 - don't use EHT with bad puncturing (punctured subchannels
   cover subchannels that are used by HE)

Hopefully these things won't really break anything outside of
a handful of hostapd tests seem misconfigured (e.g

johannes

Comments

Johannes Berg Jan. 29, 2024, 6:51 p.m. UTC | #1
On Mon, 2024-01-29 at 19:34 +0100, Johannes Berg wrote:
> 
> As part of the refactoring to more clearly determine both local
> and AP mode (HT/VHT/HE/EHT) and channel configuration, this makes
> mac80211 a bit more strict:
>  - no longer accept channel switch when the mode changes
>  - no longer use e.g. VHT if the HT channel inside of it
>    occupies the wrong spot (e.g. center 40 MHz inside 80 MHz)
>  - don't use EHT with bad puncturing (punctured subchannels
>    cover subchannels that are used by HE)
> 
> Hopefully these things won't really break anything outside of
> a handful of hostapd tests seem misconfigured (e.g
> 

Err, sorry.

The tests that are broken are mostly because of the first bullet, and we
had fixed this by:
https://lists.infradead.org/pipermail/hostap/2023-December/042218.html
but (IMHO) the justification was bad - I'd still think it's weird to
switch off e.g. EHT completely during CSA, and certainly mac80211 makes
no attempt at tracking this and reacting to it (e.g. updating rate
control to disable EHT rates), which is why I did the change to not
accept it, and disconnect (which should lead to reconnect).

The EHT puncturing tests are broken because of the last bullet, and I
had fixed that in a patch I just sent to the list, but due to the second
bullet those tests are _still_ failing, and I'm not right now sure why.
But I think we can agree that the second and third bullet changes are
reasonable, and the tests need updating.

johannes
Johannes Berg Jan. 29, 2024, 6:52 p.m. UTC | #2
On Mon, 2024-01-29 at 19:51 +0100, Johannes Berg wrote:
> On Mon, 2024-01-29 at 19:34 +0100, Johannes Berg wrote:
> > 
> > As part of the refactoring to more clearly determine both local
> > and AP mode (HT/VHT/HE/EHT) and channel configuration, this makes
> > mac80211 a bit more strict:
> >  - no longer accept channel switch when the mode changes
> >  - no longer use e.g. VHT if the HT channel inside of it
> >    occupies the wrong spot (e.g. center 40 MHz inside 80 MHz)
> >  - don't use EHT with bad puncturing (punctured subchannels
> >    cover subchannels that are used by HE)
> > 
> > Hopefully these things won't really break anything outside of
> > a handful of hostapd tests seem misconfigured (e.g
> > 
> 
> Err, sorry.
> 
> The tests that are broken are mostly because of the first bullet, and we
> had fixed this by:
> https://lists.infradead.org/pipermail/hostap/2023-December/042218.html
> but (IMHO) the justification was bad - I'd still think it's weird to
> switch off e.g. EHT completely during CSA, and certainly mac80211 makes
> no attempt at tracking this and reacting to it (e.g. updating rate
> control to disable EHT rates), which is why I did the change to not
> accept it, and disconnect (which should lead to reconnect).
> 
> The EHT puncturing tests are broken because of the last bullet, and I
> had fixed that in a patch I just sent to the list,

https://lists.infradead.org/pipermail/hostap/2024-January/042316.html

johannes