Message-Id: <C3F2FB99-C022-4BEE-8F1C-8B6F0E14DAA1@holtmann.org>
Date: Thu, 21 Dec 2023 21:39:25 +0100
From: Marcel Holtmann <marcel@...tmann.org>
To: Julian Calaby <julian.calaby@...il.com>
Cc: Arend van Spriel <arend.vanspriel@...adcom.com>,
 Kalle Valo <kvalo@...nel.org>,
 Hector Martin <marcan@...can.st>,
 Arend van Spriel <aspriel@...il.com>,
 Franky Lin <franky.lin@...adcom.com>,
 Hante Meuleman <hante.meuleman@...adcom.com>,
 Daniel Berlin <dberlin@...rlin.org>,
 linux-wireless@...r.kernel.org,
 brcm80211-dev-list.pdl@...adcom.com,
 SHA-cyfmac-dev-list@...ineon.com,
 linux-kernel@...r.kernel.org,
 asahi@...ts.linux.dev
Subject: Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password

Hi Julian,

>>>>>> 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@...can.st>
>>>>>> Reviewed-by: Neal Gompa <neal@...pa.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.

Regards

Marcel

Powered by blists - more mailing lists