luci-mod-network: hide incompatible encryption modes for 6 GHz

[micpf]

The WiFi 6E (6 GHz) standard mandates WPA3 and management frame
protection. While wifi-scripts already silently upgrades mixed modes
(psk-sae → sae) on 6 GHz radios, the LuCI encryption dropdown still
offers all WPA2/WPA/WEP options, leading to confusing hostapd failures
when users pick an unsupported mode.

When the radio band is 6 GHz, hide encryption options that are
incompatible with the standard:

• WPA2-PSK, WPA-PSK, WPA-PSK/WPA2-PSK Mixed Mode
• WPA2-PSK/WPA3-SAE Mixed Mode (6 GHz does not allow WPA2 fallback)
• WPA2-EAP, WPA-EAP, WPA2-EAP/WPA3-EAP Mixed Mode
• WEP

This leaves WPA3-SAE, WPA3-EAP, WPA3-EAP 192-bit, OWE, and No
Encryption as the available choices for 6 GHz interfaces.

There is a companion fix for openwrt/openwrt wifi-scripts that extends
the existing 6 GHz auth_type override to also cover pure WPA2 modes
(psk, eap), upgrading them to their WPA3 equivalents as a safety net.

[OpenWRT-fanboy]

It's been a long time coming.

#7553

[micpf]

It's been a long time coming.

#7553

I see, so others also fell for this trap. We got this as customer feedback, and I was about to patch our build. But I thought this might be of interest upstream.

[openwrt-ai]

Reviewed the 6 GHz encryption-mode filtering. The band detection (uci.get('wireless', radioNet.getWifiDeviceName(), 'band') == '6g') is consistent with existing usage in this file, and narrowing the dropdown to WPA3/OWE on 6 GHz matches the wifi-scripts behavior in package/network/config/wifi-scripts/.../ap.uc (it forces PMF and SAE on 6 GHz). Two points left inline: one on preserving an already-configured incompatible mode on a 6 GHz radio, and one nit on the PR body vs commit message disagreeing about whether "No Encryption" stays available.

---

Generated by Claude Code

[openwrt-ai]

This filters the dropdown by band, but it does not account for a section that already stores a now-hidden mode. If a 6 GHz interface was previously configured with, say, psk2 (imported config, set before this change, or via another band assignment), that value is no longer pushed into crypto_modes, so encr.value() never registers it. The encryption ListValue would then render with no matching option selected, and saving the form risks silently dropping or rewriting the stored encryption value rather than surfacing the incompatibility to the user.

Worth confirming the migration path: does the dropdown still show (and preserve) an existing incompatible value on a 6 GHz radio, or does it blank out? If it blanks, consider pushing the configured value as a disabled/flagged option so the user sees what is set before changing it.

---

Generated by Claude Code

[micpf]

Regarding the migration path: if a 6 GHz interface already has an incompatible mode stored (e.g. psk2), that configuration never actually worked — hostapd rejects it with an "Invalid AKM suite" error and the radio doesn't come up. The ListValue defaults to the first available option when the stored value isn't in the list, so the user sees an obviously different selection and must actively save to apply it. This surfaces the broken config rather than silently preserving it, which seems like the right UX here.

[openwrt-ai]

nit: the PR description and this commit disagree about none. The PR body lists "No Encryption" among the choices that remain available for 6 GHz ("This leaves WPA3-SAE, WPA3-EAP, WPA3-EAP 192-bit, OWE, and No Encryption..."), but the commit message lists "No Encryption" under the hidden options, which is what this hunk actually does. Please reconcile the PR body with the commit message/code so the intended behavior is unambiguous.

---

Generated by Claude Code

[micpf]

Good catch — the PR body was stale from before the "No Encryption" fix. Updated it to match the commit message.