On Tue Nov 25, 2025 at 10:30 PM CET, Stefan Sperling wrote:
> 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?

Yes it connects whrn I disable PMF for the SSID.
--> openbsd-arista_pmf-disabled_r-optional.pcap

> 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"?

No success when I disable 11r but keep 11w required. Also not with the
patch below applied on top of the PMF patches.
--> openbsd-arista_pmf-required_r-disabled.pcap

>
> 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.
>

• openbsd-arista_pmf-disabled_r-optional.pcap (5K)
• openbsd-arista_pmf-required_r-disabled.pcap (712B)