luci-mod-network: add WiFi 7 (802.11be / EHT) advanced configuration options

[prokowsoftware]

Summary

PR #7302 (merged Oct 2024) added basic 802.11be mode selection (EHT htmodes) but did not expose advanced EHT-specific configuration options in the UI. This PR adds the missing options.

New options in the Advanced tab (radio device):

• Disable EHT (802.11be) (disable_eht) — fall back to 802.11ax (WiFi 6 / HE)
• Punctured Channel Bitmap (punct_bitmap) — bitmask of 20 MHz sub-channels to exclude; shown only for EHT160 and EHT320 modes
• EHT SU Beamformer (eht_su_beamformer) — enable Single-User Transmit Beamformer capability
• EHT MU Beamformer (eht_mu_beamformer) — enable Multi-User Transmit Beamformer capability

New option in the Wireless Security tab (interface):

• SAE Password Element (sae_pwe) — selects the mechanism for SAE password element derivation (H&P, H2E, or both); H2E is required for WiFi 7 on 6 GHz; shown only for sae and sae-mixed encryption modes

Testing

Tested on a Radxa device with QCN9274 (802.11be) card running OpenWrt.

[castiel652]

• Disable EHT (802.11be) (disable_eht) — fall back to 802.11ax (WiFi 6 / HE)

Is this for client mode?

[prokowsoftware]

• Disable EHT (802.11be) (disable_eht) — fall back to 802.11ax (WiFi 6 / HE)

Is this for client mode?

No, disable_eht here is for AP mode only. In a typical deployment, the AP advertises its capabilities via beacons and the client adapts accordingly — so disabling EHT on the AP side is sufficient to fall back to 802.11ax (HE).

disable_eht is also supported by wpa_supplicant (client mode), but that use case is niche — it would only be needed if you want a station to avoid EHT even when the AP offers it (e.g. for debugging or compatibility testing). We didn't include it here as it's outside the scope of this PR.

[castiel652]

No, disable_eht here is for AP mode only. In a typical deployment, the AP advertises its capabilities via beacons and the client adapts accordingly — so disabling EHT on the AP side is sufficient to fall back to 802.11ax (HE).

Okay so what's the point of this option?
Just select AX mode?

[prokowsoftware]

Good question. The difference is subtle but useful in practice:

When you set htmode to an HE (WiFi 6) mode, you reconfigure the entire radio — channel width, beamforming, everything — for 802.11ax.

disable_eht lets you keep your EHT channel configuration (e.g. EHT320) but disable the 802.11be-specific features, so the AP falls back to HE for client associations. This is useful for:

• Compatibility testing — verifying how your network behaves without EHT without changing the channel plan
• Mixed environments — keeping a wide channel (320 MHz) while serving older clients that struggle with EHT negotiation
• Debugging — isolating whether an issue is EHT-specific

If you want to permanently run in WiFi 6 mode, yes — just select an HE htmode. disable_eht is more of a diagnostic/transitional toggle.

[prokowsoftware]

To be honest, the main motivation for this PR was sae_pwe. We were unable to properly configure our AP with WPA3/SAE — clients kept failing to associate — until we set sae_pwe=2 (H&P + H2E). Without this option exposed in the UI, it required manual UCI editing every time.

The EHT options came along naturally as we were already working with WiFi 7 hardware (QCN9274) and the wireless configuration page.

[prokowsoftware]

We are also waiting for a newer kernel in OpenWrt (6.12+) to properly support MLO (Multi-Link Operation). Once that lands in a stable release, we plan to extend this with MLO configuration options as well.

[castiel652]

• Mixed environments — keeping a wide channel (320 MHz) while serving older clients that struggle with EHT negotiation

320MHz is EHT only.

until we set sae_pwe=2 (H&P + H2E).

Which version of OpenWrt are you using?
AFAIK this is the default since 22.03.

[systemcrash]

And the additional options are available in the wifi scripts?

[Neustradamus]

@prokowsoftware: Nice work, thanks!

Have you seen recent @castiel652 and @systemcrash comments?

[prokowsoftware]

Thanks for the review, @castiel652 and @systemcrash!

---

320MHz is EHT only.

You're correct, and thank you for the correction. 320 MHz channel width is defined exclusively in IEEE 802.11be (EHT) - there is no 802.11ax (HE) equivalent. Using disable_eht with EHT320 would force the AP to fall back to 160 MHz at most for HE associations. That part of my description was inaccurate.

The realistic use cases for disable_eht are:

• Keeping an EHT80/EHT160 channel plan while temporarily forcing 802.11ax associations (e.g., compatibility testing without changing the channel width)
• Isolating whether a connectivity issue is EHT-specific

---

AFAIK sae_pwe is the default since 22.03.

Even if hostapd's compiled-in default is correct, the option was not exposed in the LuCI UI - so users had no way to see what value was in effect or change it without manual UCI editing.

In our specific case (OpenWrt 24.10, QCN9274, 6 GHz), client associations were failing with WPA3/SAE until we explicitly set sae_pwe 2 via UCI. Whether that was a default issue or something hardware/driver-specific, having the option visible in the UI makes it debuggable and explicit - which is useful regardless of the default.

This PR targets OpenWrt 24.10, where the EHT htmodes were introduced in #7302.

---

And the additional options are available in the wifi scripts?

Yes - all five options map to hostapd configuration keys that are handled by OpenWrt's mac80211.sh wireless scripts in 24.10:

UCI option	hostapd config key
disable_eht	disable_eht
punct_bitmap	punct_bitmap
eht_su_beamformer	eht_su_beamformer
eht_mu_beamformer	eht_mu_beamformer
sae_pwe	sae_pwe

We tested disable_eht, punct_bitmap, and sae_pwe on a Radxa device with QCN9274 (802.11be) running OpenWrt 24.10. If any of these are missing from the wireless scripts for other branches, that would be a separate issue in openwrt/openwrt.

[castiel652]

• Keeping an EHT80/EHT160 channel plan while temporarily forcing 802.11ax associations (e.g., compatibility testing without changing the channel width)

Use HE80/HE160?????

In our specific case (OpenWrt 24.10, QCN9274, 6 GHz), client associations were failing with WPA3/SAE until we explicitly set sae_pwe 2 via UCI. Whether that was a default issue or something hardware/driver-specific, having the option visible in the UI makes it debuggable and explicit - which is useful regardless of the default.

You should check the hostapd conf file

This PR targets OpenWrt 24.10, where the EHT htmodes were introduced in #7302.

No. This PR targets master branch. Check again.

Yes - all five options map to hostapd configuration keys that are handled by OpenWrt's mac80211.sh wireless scripts in 24.10:

Are you sure about the first four options?

[systemcrash]

Is this for 24.10 only? ( meaning that 25.12 works fine? )

[prokowsoftware]

@systemcrash @castiel652 — thanks for the continued discussion!

To answer your question directly: we're planning to test the latest OpenWrt (25.x) this week. Our changes were developed and tested against 24.10.2, so we haven't yet verified whether they're required on the latest tree or whether some of the issues we encountered (particularly the sae_pwe default and EHT-related UI behavior) are already addressed there.

We'll report back once we've had a chance to run through it on current master.