[25.12]: Improve WPA 3 compatibility and add additional options#23011
Open
hauke wants to merge 12 commits intoopenwrt:openwrt-25.12from
Open
[25.12]: Improve WPA 3 compatibility and add additional options#23011hauke wants to merge 12 commits intoopenwrt:openwrt-25.12from
hauke wants to merge 12 commits intoopenwrt:openwrt-25.12from
Conversation
hauke
changed the title
hauke
force-pushed
the
improve-wpa3-25.12
branch
from
8b9ce1e to
e94016c
Compare
github-actions
Bot
added
core packages
hauke
force-pushed
the
improve-wpa3-25.12
branch
from
e94016c to
71b803b
Compare
hauke
changed the title
hauke
force-pushed
the
improve-wpa3-25.12
branch
3 times, most recently
from
f7523f7 to
b6501e1
Compare
openwrt-ai
reviewed
May 2, 2026
sae_require_mfp and sae_pwe are SAE-specific knobs but iface_auth_type() set them on every auth type that requires PMF (sae, owe, eap2, eap192, dpp) and on both PMF-optional transition modes (psk-sae, eap-eap2). hostapd silently ignores the stray settings on non-SAE BSSes, but they clutter the generated configuration and make it harder to tell at a glance which knobs actually apply. Split the grouping: keep ieee80211w (and rsn_override_mfp for transition modes) where it was, and move sae_require_mfp / sae_pwe into a separate check that only fires for the two auth types that actually run SAE (sae and psk-sae). No functional change on the air. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 9aeea77)
The rsn_override UCI number was scaffolding that let a Transition
Mode BSS (sae-mixed, wpa3-mixed) automatically overlay a WPA3
Compatibility-Mode-like layout: WPA3 AKMs were moved from the main
RSNE into RSNOE/RSNO2E, and with rsn_override=2 the main RSNE even
dropped SAE entirely to placate clients that refuse to associate to
a mixed AKM list.
This layout does not match any mode defined in the WPA3 and Wi-Fi
Enhanced Open Deployment and Implementation Guide v1.1: Transition
Mode (Table 5) advertises the full AKM list in a single RSNE, and
Compatibility Mode (§2.4, Tables 6 and 7) requires a specific
combination of RSNE, RSNOE and RSNO2E contents that the knob cannot
express. In practice it also triggers interop failures: Pixel 10
phones refuse to associate to a Transition-Mode BSS whose SAE-EXT-KEY
AKM has been shoved into RSNO2E by this scaffolding, even though the
same BSS works fine when the full AKM list stays in the main RSNE.
Keep the generated configuration honest by removing the knob; the RSN
override plumbing stays in place for a future caller that sets the
override fields explicitly. SAE-EXT-KEY advertisement will be added
back in a later commit via a dedicated sae_ext_key path that places
the AKM where the Deployment Guide actually requires it.
Drop the rsn_override schema entry and every wifi-scripts path that
read it:
* parse_encryption no longer diverts the WPA3 pairwise cipher
into rsn_override_pairwise.
* wpa_key_mgmt no longer mirrors WPA-EAP into
rsn_override_key_mgmt, moves SAE/SAE-EXT-KEY into the override
for psk-sae, or drops the main RSNE AKM list when
rsn_override > 1.
* generate() no longer back-fills missing rsn_override_* fields
from the main RSNE or duplicates the override element into an
MLO-gated RSNO2E.
The RSN override elements are now emitted only when each of
(rsn_override_key_mgmt, rsn_override_pairwise, rsn_override_mfp) --
and their _2 counterparts -- has been populated explicitly, which
keeps the machinery from firing on transition modes where it was
never spec-compliant.
Fixes: openwrt#21486
Fixes: openwrt#22200
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: openwrt#23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 588330e)
parse_encryption() stashed a preliminary wpa_pairwise value in a local wpa3_pairwise variable, cleared it per auth_type, then let a switch default either copy it back or special-case wpa3-192. The result was three separate places where wpa_pairwise was clobbered and behavior that was awkward to trace when the explicit cipher suffix (encryption[1]) and the auth_type disagreed. Replace the scaffolding with a single block at the end of parse_encryption() that only assigns wpa_pairwise via ??= when no earlier branch (explicit cipher suffix, wpa3-192, or sae-compat) has already set one: no WPA -> null 60 GHz (hw_mode=ad) -> GCMP HE or EHT htmode -> GCMP-256 CCMP everything else -> CCMP wpa3-192 now sets wpa_pairwise='GCMP-256' directly in its switch case, so the final default block can stay short. No functional change for existing encryption values. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 1f86f4e)
WPA3 Specification v3.5 §2.5.4 mandates that an AP's BSS Configuration enables AKM suite selector 00-0F-AC:24 (SAE-EXT-KEY, SAE with a group-dependent hash) whenever EHT or MLO is enabled. The WPA3 and Wi-Fi Enhanced Open Deployment Guide v1.1 also recommends it on non-EHT APs (Tables 3, 5, 6, 8). Add a new sae_ext_key UCI option (enabled by default) that advertises SAE-EXT-KEY, and FT-SAE-EXT-KEY when 802.11r is enabled, alongside plain SAE/FT-SAE for the sae and psk-sae encryption modes. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit a12cec9)
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide v1.1, Table 4 (Common security configuration) marks Beacon Protection as MAND for EHT-enabled APs and RECOM otherwise for all WPA3 and Wi-Fi Enhanced Open modes. The ucode path blindly passed beacon_prot through from UCI in iface setup, which ran before encryption and MFP had been configured, and left hostapd at its insecure default of 0 when the user did not explicitly opt in. Default beacon_prot to 1 in iface_mfp after MFP has been confirmed to be enabled, and emit it there instead of in iface_setup so the option is only written when PMF support is actually negotiated. Users can still disable it explicitly via UCI. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit ef393ca)
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide v1.1 §2.4 (Tables 6 and 7) defines WPA3-Personal Compatibility Mode: the AP advertises a legacy-looking RSNE (WPA-PSK, CCMP-128, PMF Disabled) while RSN Override Elements layered on top expose SAE and, on EHT, SAE-EXT-KEY. WPA2-only STAs and STAs that ignore RSN Overriding associate unchanged; modern STAs pick up the stronger WPA3 AKM via RSNOE or RSNO2E. Only the pairwise cipher differs between elements: RSNE and RSNOE advertise CCMP-128, RSNO2E advertises GCMP-256 (EHT only). Group data (CCMP-128) and group management cipher (BIP-CMAC-128) are the same in all three per Tables 6/7, so hostapd's BSS-wide group_cipher and group_mgmt_cipher singletons produce the spec-correct values. Unlike WPA3-Personal Transition Mode (sae-mixed), which puts PSK and SAE together in the main RSNE with PMF Capable, Compatibility Mode keeps the main RSNE strictly WPA2-shaped so clients that choke on a mixed AKM list or PMF=Capable still see a pure WPA2 BSS. The trade- off is that clients without RSN Overriding support never pick up SAE. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 86b9eec)
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide v1.1 (Tables 7 and 8) mandates "H2E Only" for SAE on 6 GHz, in both WPA3-Personal Only and WPA3-Personal Compatibility Mode: the 6 GHz band disallows the legacy Hunting-and-Pecking password element, so the AP must advertise BSS Membership Selector 123 to force STAs onto H2E. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 3b22050)
WPA3 Specification v3.5 §13 defines the Transition Disable element sent
inside message 3 of the 4-way handshake. An AP that is no longer
offering a transition mode for its SSID sets the matching bit so that
compliant STAs permanently stop falling back to WPA-PSK / WPA-EAP /
open for that SSID, hardening against downgrade attacks and against
operator mistakes where a transition-mode BSS is briefly brought up on
an SSID that previously ran WPA3-only.
Expose this as a UCI list 'transition_disable' with three classes of
entries:
* The existing OpenWrt encryption tokens 'sae' (bit 0x01), 'sae-pk'
(0x02), 'wpa3' (0x04) and 'owe' (0x08) OR into the bitmap. SAE-PK
itself is not yet wired through wifi-scripts; the token only lets
an operator who configured SAE-PK out of band also hand the
matching bit to hostapd.
* 'on' derives the bitmap from the AP's auth_type ('sae' -> 0x01,
'eap2'/'eap192' -> 0x04, pure 'owe' -> 0x08) and overrides any
other explicit tokens in the same list. Transition BSSes
(psk-sae, eap-eap2, owe with owe_transition set) produce no
bits even under 'on' because they are by definition still in
transition.
* 'off' unconditionally suppresses the element regardless of any
other entries. Operators who need to revert a WPA3-only SSID back
to a transition mode can set this proactively, giving compliant
STAs time to forget the permanent bit before the mode change.
Leave the list unset by default. Advertising Transition Disable is a
one-way door -- once a compliant STA has seen the permanent bit for an
SSID it will refuse to associate to a transition-mode BSS of the same
name ever again -- so it must be opted in to per SSID, never flipped
on by a firmware bump. This also matches the WPA3 and Wi-Fi Enhanced
Open Deployment and Implementation Guide v1.1 Table 4 requirement that
Transition Disable be MAND disabled by default on APs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: openwrt#23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 2db148c)
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide v1.1 (Tables 4, 5, 6) requires the group-management cipher (BIP) to match the mode and strength of the pairwise cipher: GCM-mode pairwise ciphers pair with BIP-GMAC integrity, CCM-mode pairwise ciphers with BIP-CMAC integrity. The ucode pipeline hard-coded group_mgmt_cipher to AES-128-CMAC (BIP-CMAC-128) regardless of the pairwise cipher, except for the eap192 special case that already forced BIP-GMAC-256. An EHT WPA3-Personal BSS therefore emitted wpa_pairwise=GCMP-256 alongside group_mgmt_cipher=AES-128-CMAC -- the integrity cipher two steps weaker than the data cipher and a spec violation on EHT. hostapd has a single group_mgmt_cipher knob, so the selected BIP has to be compatible with every pairwise cipher in wpa_pairwise. Picking from the first token would mis-select on mixed lists -- e.g. wpa_pairwise=\"GCMP-256 CCMP\" would yield BIP-GMAC-256, which a CCMP-only STA cannot negotiate. Walk the wpa_pairwise tokens and pick the BIP that matches the weakest cipher present: CCMP / TKIP -> AES-128-CMAC (BIP-CMAC-128) CCMP-256 -> BIP-CMAC-256 GCMP -> BIP-GMAC-128 GCMP-256 -> BIP-GMAC-256 Token matching uses fnmatch wildcards against a copy of wpa_pairwise that is padded with leading and trailing spaces, so each token is space-bounded regardless of its position in the list. The RSN override pairwise lists are not consulted: in the only caller that sets them (WPA3-Personal Compatibility Mode), Tables 6 and 7 require BIP-CMAC-128 across RSNE/RSNOE/RSNO2E even when the override lists advertise GCMP-256, so wpa_pairwise=CCMP already yields the correct BIP. An explicit ieee80211w_mgmt_cipher UCI value still wins over the derived default. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 68165c8)
The WPA3 and Wi-Fi Enhanced Open Deployment Guide v1.1 (Table 4, "SAE Groups") recommends that WPA3-Personal APs advertise support for SAE groups 19, 20 and 21: * group 19 - ECP 256-bit (NIST P-256) * group 20 - ECP 384-bit (NIST P-384) * group 21 - ECP 521-bit (NIST P-521) hostapd's default is group 19 only, which leaves the two larger ECP groups unavailable even though the peer may prefer them. Set sae_groups = "19 20 21" as the default for any BSS whose auth_type is sae or psk-sae (SAE, SAE Transition and SAE Compatibility modes). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 0ca11b3)
Two of the IW_FULL guards in 200-reduce_size.patch were inverted or incomplete: * the "unknown event" handler unconditionally replaced the verbose print with the short form, so IW_FULL builds lost the command name decoding; * the early return before the vendor IE parser used #ifdef IW_FULL, which suppressed parsing in the full build instead of the size-reduced one. Wrap both with the correct #ifndef IW_FULL / #else so the full and reduced builds produce the intended output. Link: openwrt#23009 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 957b921)
Backport upstream iw commit d90618809e06 ("iw: scan: print RSN
Element Override IEs") as 001-*.patch so `iw scan` decodes the
RSNOE (vendor WFA type 41) and RSNO2E (type 42) elements that
hostapd emits for WPA3 Compatibility / RSN Overriding APs.
Also refresh the hunk offsets in 200-reduce_size.patch.
Link: openwrt#23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 164428d)
openwrt-ai
reviewed
May 3, 2026
Collaborator
openwrt-ai
left a comment
openwrt-ai
left a comment
There was a problem hiding this comment.
Rebased onto a newer openwrt-25.12 base; the 12 PR-authored commits are content-identical to the previous review (matching git patch-id). No new issues found.
Generated by Claude Code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These are multiple independent commits which are activating some features which are mandatory in Wifi 7 and make some optional options configurable by the users. This should fix some compatibility problems we see with Pixel 10 and other wifi devices.
Cherry pick of #23009