Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password

[Marcel Holtmann <marcel@holtmann.org>]

Hi Neal,

>>>>>>>> Using the WSEC command instead of sae_password seems to be the supported
>>>>>>>> mechanism on newer firmware, and also how the brcmdhd driver does it.
>>>>>>>> 
>>>>>>>> According to user reports [1], the sae_password codepath doesn't actually
>>>>>>>> work on machines with Cypress chips anyway, so no harm in removing it.
>>>>>>>> 
>>>>>>>> This makes WPA3 work with iwd, or with wpa_supplicant pending a support
>>>>>>>> patchset [2].
>>>>>>>> 
>>>>>>>> [1] https://rachelbythebay.com/w/2023/11/06/wpa3/
>>>>>>>> [2] http://lists.infradead.org/pipermail/hostap/2023-July/041653.html
>>>>>>>> 
>>>>>>>> Signed-off-by: Hector Martin <marcan@marcan.st>
>>>>>>>> Reviewed-by: Neal Gompa <neal@gompa.dev>
>>>>>>> 
>>>>>>> Arend, what do you think?
>>>>>>> 
>>>>>>> We recently talked about people testing brcmfmac patches, has anyone else
>>>>>>> tested this?
>>>>>> 
>>>>>> Not sure I already replied so maybe I am repeating myself. I would prefer
>>>>>> to keep the Cypress sae_password path as well although it reportedly does
>>>>>> not work. The vendor support in the driver can be used to accommodate for
>>>>>> that. The other option would be to have people with Cypress chipset test
>>>>>> this patch. If that works for both we can consider dropping the
>>>>>> sae_password path.
>>>>>> 
>>>>>> Regards,
>>>>>> Arend
>>>>> 
>>>>> So, if nobody from Cypress chimes in ever, and nobody cares nor tests
>>>>> Cypress chipsets, are we keeping any and all existing Cypress code-paths
>>>>> as bitrotting code forever and adding gratuitous conditionals every time
>>>>> any functionality needs to change "just in case it breaks Cypress" even
>>>>> though it has been tested compatible on Broadcom chipsets/firmware?
>>>>> 
>>>>> Because that's not sustainable long term.
>>>> 
>>>> You should look into WEXT just for the fun of it. If it were up to me
>>>> and a bunch of other people that would have been gone decades ago. Maybe
>>>> a bad example if the sae_password is indeed not working, but the Cypress
>>>> chipset is used in RPi3 and RPi4 so there must be a couple of users.
>>> 
>>> There are reports that WPA3 is broken on the Cypress chipsets the
>>> Raspberry Pis are using and this patch fixes it:
>>> https://rachelbythebay.com/w/2023/11/06/wpa3/
>>> 
>>> Based on that, it appears that all known users of WPA3 capable
>>> hardware with this driver require this fix.
>> 
>> the Pis are all using an outdated firmware. In their distro they put the
>> firmware already under the alternates systems, but it just lacks the SAE
>> offload support that is required to make WPA3 work. The linux-firmware
>> version does the trick nicely.
>> 
>> I documented what I did to make this work on Pi5 (note that I normally
>> use Fedora on Pi4 and thus never encountered this issue)
>> 
>> https://holtmann.dev/enabling-wpa3-on-raspberry-pi/
>> 
>> However you need to use iwd and not hope that you get a wpa_supplicant
>> released version that will work.
>> 
>> So whole game of wpa_supplicant is vendor specific to the company that
>> provides the driver is also insane, but that is another story. Use iwd
>> and you can most likely have WPA3 support if you have the right firmware.
>> 
> 
> wpa_supplicant is perfectly fine if the necessary patches are
> backported, as Fedora has done:
> https://src.fedoraproject.org/rpms/wpa_supplicant/c/99f4bf2096d3976cee01c499d7a30c1376f5f0f7

my point exactly. Tell me when the last hostap release was and how much
delta that has to HEAD. So the wpa_supplicant you have in Fedora is
essentially yet another fork of an upstream project. One of many.

Reality is there is limited interest to make WiFi great on Linux. And
if you really look honestly, then you realize it is pretty bad.

Regards

Marcel