[PATCH wireless] wifi: mac80211: use HT CCFS2 when computing the AP's HE and lower bandwidth

[PATCH wireless] wifi: mac80211: use HT CCFS2 when computing the AP's HE and lower bandwidth

[John Macias]

If the driver advertises VHT extended NSS BW support, hostapd announces
a 160 MHz BSS the way IEEE 802.11-2020 allows for that case: the VHT
Operation element has channel width 1, CCFS0 is the 80 MHz segment and
CCFS1 is 0, and the 160 MHz centre is in the CCFS2 field of the HT
Operation element.

ieee80211_calc_ap_he_and_lower() only looks at the VHT CCFS1, so it
sets bss_bw.he_and_lower to 80 MHz and ieee80211_sta_usable_bw() then
limits every HE and VHT station to 80 MHz. Stations parse CCFS2 and use
160 MHz towards the AP, but the AP never transmits wider than 80 MHz.

Take CCFS2 from the HT Operation element when the VHT CCFS1 is 0, as
the station side already does in ieee80211_chandef_vht_oper().

Seen with ath11k on IPQ8074 (it advertises extended NSS BW when the
firmware reports an NSS ratio) with an HE160 BSS on channel 36: peers
were created as 11ax-he80 and no frames were sent at 160 MHz. With this
change the peers are 11ax-he160, nearly all downlink data goes out at
160 MHz and an MT7925 client's download went from 810 to 1645 Mb/s.

Fixes: c9b62ab79133 ("wifi: mac80211: fix per-station PHY capability bandwidth")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: John Macias <dencity7@gmail.com>
---
 net/mac80211/cfg.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a1753335e..e6fd83cb7 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1366,6 +1366,13 @@ ieee80211_calc_ap_he_and_lower(struct cfg80211_beacon_data *params)
 			 */
 			ccfs0 = vht_oper->center_freq_seg0_idx;
 			ccfs1 = vht_oper->center_freq_seg1_idx;
+			/*
+			 * With extended NSS BW support the second segment
+			 * can be in the HT Operation CCFS2 field instead.
+			 */
+			if (!ccfs1 && params->ht_oper)
+				ccfs1 = le16_get_bits(params->ht_oper->operation_mode,
+						      IEEE80211_HT_OP_MODE_CCFS2_MASK);
 			if (!ccfs0)
 				return IEEE80211_STA_RX_BW_80;
 			if (ccfs1 && abs(ccfs1 - ccfs0) == 8)
-- 
2.47.3

Re: [PATCH wireless] wifi: mac80211: use HT CCFS2 when computing the AP's HE and lower bandwidth

[Johannes Berg]

On Sun, 2026-10-25 at 21:01 -0700, John Macias wrote:
> If the driver advertises VHT extended NSS BW support, hostapd announces
> a 160 MHz BSS the way IEEE 802.11-2020 allows for that case: the VHT
> Operation element has channel width 1, CCFS0 is the 80 MHz segment and
> CCFS1 is 0, and the 160 MHz centre is in the CCFS2 field of the HT
> Operation element.
> 
> ieee80211_calc_ap_he_and_lower() only looks at the VHT CCFS1, so it
> sets bss_bw.he_and_lower to 80 MHz and ieee80211_sta_usable_bw() then
> limits every HE and VHT station to 80 MHz. Stations parse CCFS2 and use
> 160 MHz towards the AP, but the AP never transmits wider than 80 MHz.
> 
> Take CCFS2 from the HT Operation element when the VHT CCFS1 is 0, as
> the station side already does in ieee80211_chandef_vht_oper().

This, by itself, is wrong.

johannes

Re: [PATCH wireless] wifi: mac80211: use HT CCFS2 when computing the AP's HE and lower bandwidth

[John Macias]

On Mon, 2026-10-26 at 12:07 +0100, Johannes Berg wrote:
> This, by itself, is wrong.

Thanks. I think I see why: CCFS2 only applies to a STA that can
interpret Extended NSS BW, and my patch applied it to every station.
Please drop it.

I looked further and may have found the actual cause, but I'm not
certain. Below I've separated what I measured from what I concluded
by reading code. Corrections are very welcome.

Setup: IPQ8074 (Netgear RAX120v1), ath11k, firmware
WLAN.HK.2.0-01792, HE160 BSS on channel 36. Clients: MT7925 and AX200.

What I measured:

- Before any change, "iw phy" on the AP reports VHT Capabilities
  0x738f09fa, prints the Supported Channel Width as "(reserved)", and
  shows "VHT extended NSS: not supported".

- In the beacon I captured for the original patch, the VHT Operation
  element has Channel Width 1 and CCFS1 0, and the 160 MHz centre is
  in the HT Operation CCFS2 field.

- Both clients report a 160 MHz link. On the AP side the peers were
  set up as 11ax-he80 and the AP's transmit rate to them stayed at
  80 MHz (MT7925 download about 810 Mb/s).

- With the change described below, "iw phy" prints "160 MHz, 80+80
  MHz" and still "VHT extended NSS: not supported". The AP then
  transmits to both clients at 160 MHz HE-MCS 11, with unmodified
  mac80211 and without my earlier patch.

What I concluded from the code, without confirming every step on the
device:

1. My reading of 0x738f09fa is Supported Channel Width Set 2 with
   Extended NSS BW Support 1. As I read Table 9-272, that combination
   isn't defined, which would fit iw printing "reserved".
   ath11k_create_vht_cap() copies the firmware's value unchanged.

2. ath11k sets SUPPORTS_VHT_EXT_NSS_BW and
   IEEE80211_VHT_EXT_NSS_BW_CAPABLE only when the firmware reports an
   NSS ratio. "extended NSS: not supported" suggests this firmware
   doesn't. I didn't print nss_ratio_enabled itself.

3. hostapd_eid_vht_operation() moves the 160 MHz centre to CCFS2 when
   the driver's capabilities include Extended NSS BW Support. That
   would explain the beacon above. I didn't capture a beacon after the
   change, so I'm assuming it now uses CCFS1 because the AP transmits
   at 160 MHz.

4. ieee80211_calc_ap_he_and_lower() reads only CCFS1, so the AP limits
   every station to 80 MHz. Since the hardware doesn't claim extended
   NSS support, this looks correct to me, and my patch was the wrong
   fix.

The change I tested clears IEEE80211_VHT_CAP_EXT_NSS_BW_MASK in
ath11k_create_vht_cap() when the firmware gives no NSS ratio.

Questions where I may still be wrong:

- Is ath11k the right place for this? Or should mac80211 or hostapd
  ignore Extended NSS BW Support in the capabilities when the driver
  doesn't set SUPPORTS_VHT_EXT_NSS_BW?

- I also tried applying CCFS2 per station (only for STAs that set
  Extended NSS BW Capable). On this hardware it changed nothing: both
  clients stayed at 80 MHz. As far as I can tell, that's because
  mac80211 clears that bit for every station when the driver lacks
  SUPPORTS_VHT_EXT_NSS_BW. On hardware that does support it, an AP
  that signals 160 MHz through CCFS2 would still be limited to 80 MHz
  by ieee80211_calc_ap_he_and_lower(). Is that expected, or is it
  handled somewhere I missed?

If the ath11k change looks right to you, I'll send it to the ath11k
list. I can also capture the beacon after the change, or print the
firmware's NSS ratio, if that would help.

John