On Tue, Nov 25, 2025 at 03:42:34PM +0100, Remi Locherer wrote:
> iwx0: - 30:86:2d:c0:37:b0  136   +32 54M   ess  privacy   rsn! "A-LAB-PSK"

This implies our WPA compat checks reject this AP.

This failure appears to be unrelated to PMF.
It is probably failing because the AP does not advertise AKM "PSK", which
would appear as "00:0f:ac 2" in the Auth Key Management (AKM) list of
the RSN information IE.

This AP provides the following choices only:

  "FT using PSK"  (00:0f:ac 4)
  "PSK SHA256"  (00:0f:ac 6)

Our stack ignores "FT using PSK" completely, and PSK SHA256 is disabled
by default. It starts getting some use with the PFM patch, but only for
encrypted broadcast management frames (which do not matter during early
connection setup).

Does a -current kernel without the PMF patch connect to this AP? If so,
could you provide a packet capture of the working case for comparison?

Are there any obvious AP settings for enabling the AKM "PSK"?
Could you try disabling fast-transition roaming (11k / 11r) in AP settings?
Perhaps this will switch "FT using PSK" to regular "PSK"?

In any case, we should fix compatibility with such APs. Maybe allowing
PSK SHA256 would help. But I am not sure if that will work yet. See below
for a quick hack to try this.
Needs a patch since SHA256 PSK cannot be enabled with ifconfig at present.

diff /usr/src
path + /usr/src
commit - b4b55818221008479b4768cda2dbc0fbbaf02119
blob - 8873924c2dbd2e7b8d122568425bbefd8d012d7c
file + sys/net80211/ieee80211_crypto.c
--- sys/net80211/ieee80211_crypto.c
+++ sys/net80211/ieee80211_crypto.c
@@ -61,7 +61,7 @@ ieee80211_crypto_attach(struct ifnet *ifp)
 	TAILQ_INIT(&ic->ic_pmksa);
 	if (ic->ic_caps & IEEE80211_C_RSN) {
 		ic->ic_rsnprotos = IEEE80211_PROTO_RSN;
-		ic->ic_rsnakms = IEEE80211_AKM_PSK;
+		ic->ic_rsnakms = IEEE80211_AKM_PSK | IEEE80211_AKM_SHA256_PSK;
 		ic->ic_rsnciphers = IEEE80211_CIPHER_CCMP;
 		ic->ic_rsngroupcipher = IEEE80211_CIPHER_CCMP;
 		ic->ic_rsngroupmgmtcipher = IEEE80211_CIPHER_BIP;