On Sun, Aug 04, 2024 at 02:23:56PM +0200, Janne Grunau wrote: > wpa_supplicant 2.11 on Linux's 6.9.y / 6.10.y brcmfmac driver runs in > authentication timeouts with WPA2-PSK and WPA3-SAE. This was reported > with Apple silicon devices using Fedora Asahi remix with a patched > driver as well as other devices without additional brcmfmac patches. See > https://bugzilla.redhat.com/show_bug.cgi?id=2302577 for some reports. > > I've bisected this to > https://w1.fi/cgit/hostap/commit/?id=41638606054a09867fe3f9a2b5523aa4678cbfa5 > "Mark authorization completed on driver indication during 4-way HS > offload". Reverting this commit on top of hostap_2_11 properly > authenticates the connections. Looking at that change and the code it > looks clearly broken to to me. As far as I can see is > `assoc_info.authorized` for the nl80211 driver only set when > QCA_WLAN_VENDOR_ATTR_ROAM_AUTH_AUTHORIZED is set (in main, I did not > check older revisions). This doesn't seem appropriate to expect this on > chipsets from different vendors. This commit is from Broadcom to fix some race conditions with the 4-way handshake offload which I'm assuming is for a Broadcom driver.. Whether that is for brcmfmac is unknown to me, though. It looks like the goal here was to move completion of the connection from the association event to EVENT_PORT_AUTHORIZED, i.e., the NL80211_CMD_PORT_AUTHORIZED event from the driver. Is that event not delivered by brcmfmac? I did not see any full wpa_supplicant debug logs for these issues based on a quick look, so I could not check that myself. > A revert looks to me like a possible/proper fix. I can send that later > if no alternative materializes. I'm inclined to revert this if it is indeed the case that NL80211_CMD_PORT_AUTHORIZED is not delivered reliably by the upstream driver and this commit was tested only with some non-upstream versions. -- Jouni Malinen PGP id EFC895FA
