Interoperability problems with GCMP-256 and (FT-)SAE-GDH

[Hauke Mehrtens]

Hi,

We want to use the modern WPA3 security features in OpenWrt, but ran 
into several interoperability problems once we enable them on the access 
point.

We try to follow the recommendations from the "WPA3 and Wi-Fi Enhanced 
Open Deployment and Implementation Guide" (Wi-Fi Alliance). With Wi-Fi 7 
(EHT) some of these recommendations become mandatory.
https://www.wi-fi.org/file/wpa3-and-wi-fi-enhanced-open-deployment-and-implementation-guide-2024

We are using hostapd from git (snapshot 2026-04-02, commit 
b004de0bf1b5), built with IEEE 802.11ax/be support. Fix there are 
improvements or fixes for these problems in more recent versions we are 
happy to cherry pick them.

Below are two BSS configurations that cause problems with real clients. 
The full discussion and the collected test results are in this OpenWrt 
pull request:
https://github.com/openwrt/openwrt/pull/23009


1) GCMP-256 as the pairwise cipher

Several clients fail to associate when GCMP-256 is offered as the 
pairwise cipher (wpa_pairwise=GCMP-256, or "GCMP-256 CCMP"), already on 
Wi-Fi 6, and connect again when only CCMP is offered. Reported for 
Nanoleaf devices, a Motorola/Unisoc phone and a Linux/iwd laptop.


2) FT-SAE-EXT-KEY (SAE-GDH combined with 802.11r / Fast Transition)

On a Wi-Fi 6 AP with 802.11r enabled and

     wpa=2
     wpa_key_mgmt=SAE SAE-EXT-KEY FT-SAE FT-SAE-EXT-KEY
     wpa_pairwise=GCMP-256 CCMP
     ieee80211w=2

a Samsung Galaxy Tab S10 FE cannot associate, while a Pixel 9a on the 
very same BSS connects fine. For the failing tablet hostapd never 
completes the association and only logs, repeatedly:

     hostapd: handle_assoc_cb: STA aa:bb:cc:dd:ee:ff not found

For this tablet the trigger is specifically FT-SAE-EXT-KEY: removing 
just that one AKM and keeping "wpa_key_mgmt=SAE SAE-EXT-KEY FT-SAE" 
restores the connection (with GCMP-256), and plain WPA3 without FT 
("wpa_key_mgmt=SAE SAE-EXT-KEY") works too.

Possibly a separate problem: with FT-SAE-EXT-KEY present, a Poco X6 does 
associate but then reboots a few seconds later (apparently a watchdog 
reset of a stuck supplicant). We only saw this with FT enabled and did 
not test that device with plain SAE-EXT-KEY.


Questions:

- Is there a more detailed or more authoritative deployment guide than
   the Wi-Fi Alliance document above that we should follow to configure
   the BSS so that as many clients as possible accept it? We now offer
   also the WPA3 compatibility mode as an option for our users. I think
   this is more of a hack for this problem and not a real solution.

- The WPA3 specification makes GCMP-256 and SAE-EXT-KEY (SAE-GDH)
   mandatory for Wi-Fi 7 (EHT / MLO). Given the problems above, is anyone
   running a Wi-Fi 7 AP that is actually compliant with the Wi-Fi
   Alliance WPA3 specification (i.e. with GCMP-256 and SAE-EXT-KEY
   enabled), and does it interoperate with common clients?

- Are there known hostapd fixes or workarounds for these interop
   problems that we might be missing in our version - something in the
   spirit of owe_ptk_workaround? In particular, does hostapd have (or
   need) a workaround for the client that breaks when FT-SAE-EXT-KEY is
   offered (case 2)?


Thanks a lot for any pointers.

Regards,
Hauke