Re: wpa_supplicant 2.11 breaks WPA2-PSK / WPA3-SAE authentication on Linux' brcmfmac

On August 10, 2024 12:43:43 PM Arend Van Spriel 
<arend.vanspriel-dY08KVG/lbpWk0Htik3J/[email protected]> wrote:

> On August 10, 2024 11:17:56 AM "Janne Grunau" <[email protected]> wrote:
>
>> Hej,
>>
>> On Sat, Aug 10, 2024, at 10:30, Jouni Malinen wrote:
>>> 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.
>
> I was surprised to see this was coming from Broadcom. I did not yet contact
> the author for more details.
>
>>>
>>
>> The following place in brcmf_bss_roaming_done() is the only place where
>> NL80211_CMD_PORT_AUTHORIZED event is posted.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c#n6402
>
> Right. This seems to be added exclusively for Fast BSS transition scenario.
>
>>
>> In my initial analysis I missed that the NL80211_CMD_PORT_AUTHORIZED is
>> delivered directly to wpa_supplicant.
>>
>>>> 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.
>>
>> I intend extend the upstream kernel driver to post
>> NL80211_CMD_PORT_AUTHORIZED after successful connection with
>> authentication offload. I expect that the change will be accepted for
>> the stable kernel. Infineon/Cypress have non-upstream patches for the
>> brcmfmac driver which implement it already.
>
> Do you have a reference to see what they have done?
>
>> A revert in wpa_supplicant might be still appropriate until exteded
>> kernel drivers are deployed. The wpa_supplicant Fedora package carries
>> the revert as patch:
>> https://src.fedoraproject.org/rpms/wpa_supplicant/c/c2eac195adadd2c48b04f8752cc46b12a351e69
>
> Agree that revert makes most sense here. So what upstream drivers use WPA
> offload. Only brcmsmac and QCA drivers?

Obviously mean brcmfmac here. Autocorrect is mostly wrong ;-)

Regards,
Arend