From: Benjamin Berg benjamin.berg@intel.com
The EHT PHY requirements state that 80 MHz must be supported on the 5 and 6 GHz bands unless the STA is 20 MHz only. So if the channel width is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and downgrade to HE.
The primary case where this can happen is if the hardware disables puncturing using IEEE80211_HW_DISALLOW_PUNCTURING.
Signed-off-by: Benjamin Berg benjamin.berg@intel.com Cc: stable@vger.kernel.org Reviewed-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Miri Korenblit miriam.rachel.korenblit@intel.com --- net/mac80211/mlme.c | 8 ++++++++ net/mac80211/tests/chan-mode.c | 30 +++++++++++++++++++++++++----- 2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 1008eb8e9b13..dd650a127a31 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -1189,6 +1189,14 @@ ieee80211_determine_chan_mode(struct ieee80211_sub_if_data *sdata, "required MCSes not supported, disabling EHT\n"); }
+ if (conn->mode >= IEEE80211_CONN_MODE_EHT && + channel->band != NL80211_BAND_2GHZ && + conn->bw_limit == IEEE80211_CONN_BW_LIMIT_40) { + conn->mode = IEEE80211_CONN_MODE_HE; + link_id_info(sdata, link_id, + "required bandwidth not supported, disabling EHT\n"); + } + /* the mode can only decrease, so this must terminate */ if (ap_mode != conn->mode) { kfree(elems); diff --git a/net/mac80211/tests/chan-mode.c b/net/mac80211/tests/chan-mode.c index 96c7b3ab2744..adc069065e73 100644 --- a/net/mac80211/tests/chan-mode.c +++ b/net/mac80211/tests/chan-mode.c @@ -2,7 +2,7 @@ /* * KUnit tests for channel mode functions * - * Copyright (C) 2024 Intel Corporation + * Copyright (C) 2024-2025 Intel Corporation */ #include <net/cfg80211.h> #include <kunit/test.h> @@ -28,6 +28,10 @@ static const struct determine_chan_mode_case { u8 vht_basic_mcs_1_4, vht_basic_mcs_5_8; u8 he_basic_mcs_1_4, he_basic_mcs_5_8; u8 eht_mcs7_min_nss; + u16 eht_disabled_subchannels; + u8 eht_bw; + enum ieee80211_conn_bw_limit conn_bw_limit; + enum ieee80211_conn_bw_limit expected_bw_limit; int error; } determine_chan_mode_cases[] = { { @@ -128,6 +132,14 @@ static const struct determine_chan_mode_case { .conn_mode = IEEE80211_CONN_MODE_EHT, .eht_mcs7_min_nss = 0x15, .error = EINVAL, + }, { + .desc = "80 MHz EHT is downgraded to 40 MHz HE due to puncturing", + .conn_mode = IEEE80211_CONN_MODE_EHT, + .expected_mode = IEEE80211_CONN_MODE_HE, + .conn_bw_limit = IEEE80211_CONN_BW_LIMIT_80, + .expected_bw_limit = IEEE80211_CONN_BW_LIMIT_40, + .eht_disabled_subchannels = 0x08, + .eht_bw = IEEE80211_EHT_OPER_CHAN_WIDTH_80MHZ, } }; KUNIT_ARRAY_PARAM_DESC(determine_chan_mode, determine_chan_mode_cases, desc) @@ -138,7 +150,7 @@ static void test_determine_chan_mode(struct kunit *test) struct t_sdata *t_sdata = T_SDATA(test); struct ieee80211_conn_settings conn = { .mode = params->conn_mode, - .bw_limit = IEEE80211_CONN_BW_LIMIT_20, + .bw_limit = params->conn_bw_limit, }; struct cfg80211_bss cbss = { .channel = &t_sdata->band_5ghz.channels[0], @@ -191,14 +203,21 @@ static void test_determine_chan_mode(struct kunit *test) 0x7f, 0x01, 0x00, 0x88, 0x88, 0x88, 0x00, 0x00, 0x00, /* EHT Operation */ - WLAN_EID_EXTENSION, 0x09, WLAN_EID_EXT_EHT_OPERATION, - 0x01, params->eht_mcs7_min_nss ? params->eht_mcs7_min_nss : 0x11, - 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, + WLAN_EID_EXTENSION, 0x0b, WLAN_EID_EXT_EHT_OPERATION, + 0x03, params->eht_mcs7_min_nss ? params->eht_mcs7_min_nss : 0x11, + 0x00, 0x00, 0x00, params->eht_bw, + params->eht_bw == IEEE80211_EHT_OPER_CHAN_WIDTH_80MHZ ? 42 : 36, + 0x00, + u16_get_bits(params->eht_disabled_subchannels, 0xff), + u16_get_bits(params->eht_disabled_subchannels, 0xff00), }; struct ieee80211_chan_req chanreq = {}; struct cfg80211_chan_def ap_chandef = {}; struct ieee802_11_elems *elems;
+ /* To force EHT downgrade to HE on punctured 80 MHz downgraded to 40 MHz */ + set_bit(IEEE80211_HW_DISALLOW_PUNCTURING, t_sdata->local.hw.flags); + if (params->strict) set_bit(IEEE80211_HW_STRICT, t_sdata->local.hw.flags); else @@ -237,6 +256,7 @@ static void test_determine_chan_mode(struct kunit *test) } else { KUNIT_ASSERT_NOT_ERR_OR_NULL(test, elems); KUNIT_ASSERT_EQ(test, conn.mode, params->expected_mode); + KUNIT_ASSERT_EQ(test, conn.bw_limit, params->expected_bw_limit); } }
Hi,
On 26/08/2025 19:26, Miri Korenblit wrote:
From: Benjamin Berg benjamin.berg@intel.com
The EHT PHY requirements state that 80 MHz must be supported on the 5 and 6 GHz bands unless the STA is 20 MHz only. So if the channel width is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and downgrade to HE.
This is wrong one way or another.
If we follow the 802.11 standard strictly [I'm going to use annex B's items so it is easier to follow], we are implementing EHTP3.3, so a non 20 MHz-Only STA has to support 80 MHz channel width, therefore a 40 MHz (max) STA would not be compliant and we have to downgrade it. The issue is that HEP3.3 also requires that a non 20 MHz-Only HE STA has to support 80 MHz channel width, therefore downgrading to HE is not ok. We have the same issue with VHTP3.3 that requires a VHT STA to support 80 MHz channel width, therefore downgrading to VHT is not okay either. So that means that the strictly compliant approach would be to disallow a 40 MHz STA in the 6 GHz band and downgrade a 40 MHz STA to HT in the 5GHz band.
If we follow the 802.11 standard more liberally, we never enforced VHTP3.3 nor HEP3.3, so why begin now with EHTP3.3?
The primary case where this can happen is if the hardware disables puncturing using IEEE80211_HW_DISALLOW_PUNCTURING.
Signed-off-by: Benjamin Berg benjamin.berg@intel.com Cc: stable@vger.kernel.org Reviewed-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Miri Korenblit miriam.rachel.korenblit@intel.com
Best regards,
Pablo MG
On Tue, 2025-08-26 at 21:02 +0200, Pablo MARTIN-GOMEZ wrote:
The EHT PHY requirements state that 80 MHz must be supported on the 5 and 6 GHz bands unless the STA is 20 MHz only. So if the channel width is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and downgrade to HE.
This is wrong one way or another.
If we follow the 802.11 standard strictly [I'm going to use annex B's items so it is easier to follow], we are implementing EHTP3.3, so a non
I ... don't think that's a good (correct?) way to phrase it. "Implement EHTP3.3" means you have 80 MHz support, which is required unless it's 20 MHz only STA. Here we're not really implementing 80 MHz support but saying that this is a requirement ...
20 MHz-Only STA has to support 80 MHz channel width, therefore a 40 MHz (max) STA would not be compliant and we have to downgrade it. The issue is that HEP3.3 also requires that a non 20 MHz-Only HE STA has to support 80 MHz channel width, therefore downgrading to HE is not ok.
Again this is misleading, HEP3.3 states no such thing, it just asks if you have it. Clause 27 states though that 40 and 80 MHz bandwidths must be supported (except for 20 MHz-only non-AP HE STA), so yes, you're still right that our downgrade is wrong, but talking about conforma items is confusing at best?
(FWIW, I've also never seen an actual statement from anyone, it really doesn't seem to be relevant in practice at all.)
We have the same issue with VHTP3.3 that requires a VHT STA to support 80 MHz channel width, therefore downgrading to VHT is not okay either.
Similarly, Clause 21, not VHTP3.3, and in this case there's not even an allowance for 20-MHz only STA. I guess VHTP3.3 is a mere formality then.
Anyway I know you meant this only as something to talk about, but I still think it's confusing, you should state the normative text that actually requires something, not the (normative) text about what the manufacturer should state for a device that claims compatibility.
So that means that the strictly compliant approach would be to disallow a 40 MHz STA in the 6 GHz band and downgrade a 40 MHz STA to HT in the 5GHz band.
Looks like, yes. We should probably do that. These are corner cases anyway though, I don't think I've ever actually seen it happen.
If we follow the 802.11 standard more liberally, we never enforced VHTP3.3 nor HEP3.3, so why begin now with EHTP3.3?
Nobody found bugs with the other ones? ;-)
Here it comes down to this actually _happening_ due some devices not allowing puncturing, and then we can't connect in the right way.
And this doesn't matter to HE, if we connect to an AP with puncturing in the 80 MHz as an 80 MHz HE station, then it _must_ have HE not punctured so only 40 MHz. Then if the HE actually moves to 80 MHz the puncturing in EHT must go away, and the HE is 80 MHz unpunctured which is fine for the HE STA, so there isn't even a bug.
The only bug would be if the downgrade happens for reasons other than puncturing (e.g. regulatory bands) but this is very unlikely in the first place.
So practically, the only issue we had with this is that for EHT and puncturing, and then the downgrade to HE basically fixes that issue and we can connect with HE even if we pretend we can do 80 MHz because as long as the puncturing is there, the AP has to use 20 or 40 MHz operation for HE (and lower of course.)
I agree though that this isn't really completely correct for HE/VHT if the downgrade were to happen for other reasons.
However, I also don't think this is an argument _against_ fixing this issue for EHT. Clearly, for EHT there's the additional practical puncturing issue that matters. Yes, the APs rate scaling might be able to cope with it eventually, but if we remain connected with EHT and pretend we're 80 MHz when we're not, then we could get RUs in the unavailable part etc. and I think rate scaling would probably not deal with that well. This is true for HE as well, of course, but see above?
johannes
linux-stable-mirror@lists.linaro.org
-
Johannes Berg -
Miri Korenblit -
Pablo MARTIN-GOMEZ