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

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

[Hector Martin]

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>
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c         | 46 +++++++++-------------
 .../broadcom/brcm80211/brcmfmac/fwil_types.h       |  2 +-
 2 files changed, 20 insertions(+), 28 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 2a90bb24ba77..138af70a33b8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1687,52 +1687,44 @@ static u16 brcmf_map_fw_linkdown_reason(const struct brcmf_event_msg *e)
 	return reason;
 }
 
-static int brcmf_set_pmk(struct brcmf_if *ifp, const u8 *pmk_data, u16 pmk_len)
+static int brcmf_set_wsec(struct brcmf_if *ifp, const u8 *key, u16 key_len, u16 flags)
 {
 	struct brcmf_pub *drvr = ifp->drvr;
 	struct brcmf_wsec_pmk_le pmk;
 	int err;
 
+	if (key_len > sizeof(pmk.key)) {
+		bphy_err(drvr, "key must be less than %zu bytes\n",
+			 sizeof(pmk.key));
+		return -EINVAL;
+	}
+
 	memset(&pmk, 0, sizeof(pmk));
 
-	/* pass pmk directly */
-	pmk.key_len = cpu_to_le16(pmk_len);
-	pmk.flags = cpu_to_le16(0);
-	memcpy(pmk.key, pmk_data, pmk_len);
+	/* pass key material directly */
+	pmk.key_len = cpu_to_le16(key_len);
+	pmk.flags = cpu_to_le16(flags);
+	memcpy(pmk.key, key, key_len);
 
-	/* store psk in firmware */
+	/* store key material in firmware */
 	err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SET_WSEC_PMK,
 				     &pmk, sizeof(pmk));
 	if (err < 0)
 		bphy_err(drvr, "failed to change PSK in firmware (len=%u)\n",
-			 pmk_len);
+			 key_len);
 
 	return err;
 }
 
+static int brcmf_set_pmk(struct brcmf_if *ifp, const u8 *pmk_data, u16 pmk_len)
+{
+	return brcmf_set_wsec(ifp, pmk_data, pmk_len, 0);
+}
+
 static int brcmf_set_sae_password(struct brcmf_if *ifp, const u8 *pwd_data,
 				  u16 pwd_len)
 {
-	struct brcmf_pub *drvr = ifp->drvr;
-	struct brcmf_wsec_sae_pwd_le sae_pwd;
-	int err;
-
-	if (pwd_len > BRCMF_WSEC_MAX_SAE_PASSWORD_LEN) {
-		bphy_err(drvr, "sae_password must be less than %d\n",
-			 BRCMF_WSEC_MAX_SAE_PASSWORD_LEN);
-		return -EINVAL;
-	}
-
-	sae_pwd.key_len = cpu_to_le16(pwd_len);
-	memcpy(sae_pwd.key, pwd_data, pwd_len);
-
-	err = brcmf_fil_iovar_data_set(ifp, "sae_password", &sae_pwd,
-				       sizeof(sae_pwd));
-	if (err < 0)
-		bphy_err(drvr, "failed to set SAE password in firmware (len=%u)\n",
-			 pwd_len);
-
-	return err;
+	return brcmf_set_wsec(ifp, pwd_data, pwd_len, BRCMF_WSEC_PASSPHRASE);
 }
 
 static void brcmf_link_down(struct brcmf_cfg80211_vif *vif, u16 reason,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 611d1a6aabb9..b68c46caabe8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -584,7 +584,7 @@ struct brcmf_wsec_key_le {
 struct brcmf_wsec_pmk_le {
 	__le16  key_len;
 	__le16  flags;
-	u8 key[2 * BRCMF_WSEC_MAX_PSK_LEN + 1];
+	u8 key[BRCMF_WSEC_MAX_SAE_PASSWORD_LEN];
 };
 
 /**

---
base-commit: ffc253263a1375a65fa6c9f62a893e9767fbebfa
change-id: 20231107-brcmfmac-wpa3-9e5f66e8be34

Best regards,
-- 
Hector Martin <marcan@marcan.st>

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

[Neal Gompa]

On Tue, Nov 7, 2023 at 1:06 AM Hector Martin <marcan@marcan.st> wrote:
>
> 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>
> ---
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c         | 46 +++++++++-------------
>  .../broadcom/brcm80211/brcmfmac/fwil_types.h       |  2 +-
>  2 files changed, 20 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 2a90bb24ba77..138af70a33b8 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -1687,52 +1687,44 @@ static u16 brcmf_map_fw_linkdown_reason(const struct brcmf_event_msg *e)
>         return reason;
>  }
>
> -static int brcmf_set_pmk(struct brcmf_if *ifp, const u8 *pmk_data, u16 pmk_len)
> +static int brcmf_set_wsec(struct brcmf_if *ifp, const u8 *key, u16 key_len, u16 flags)
>  {
>         struct brcmf_pub *drvr = ifp->drvr;
>         struct brcmf_wsec_pmk_le pmk;
>         int err;
>
> +       if (key_len > sizeof(pmk.key)) {
> +               bphy_err(drvr, "key must be less than %zu bytes\n",
> +                        sizeof(pmk.key));
> +               return -EINVAL;
> +       }
> +
>         memset(&pmk, 0, sizeof(pmk));
>
> -       /* pass pmk directly */
> -       pmk.key_len = cpu_to_le16(pmk_len);
> -       pmk.flags = cpu_to_le16(0);
> -       memcpy(pmk.key, pmk_data, pmk_len);
> +       /* pass key material directly */
> +       pmk.key_len = cpu_to_le16(key_len);
> +       pmk.flags = cpu_to_le16(flags);
> +       memcpy(pmk.key, key, key_len);
>
> -       /* store psk in firmware */
> +       /* store key material in firmware */
>         err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SET_WSEC_PMK,
>                                      &pmk, sizeof(pmk));
>         if (err < 0)
>                 bphy_err(drvr, "failed to change PSK in firmware (len=%u)\n",
> -                        pmk_len);
> +                        key_len);
>
>         return err;
>  }
>
> +static int brcmf_set_pmk(struct brcmf_if *ifp, const u8 *pmk_data, u16 pmk_len)
> +{
> +       return brcmf_set_wsec(ifp, pmk_data, pmk_len, 0);
> +}
> +
>  static int brcmf_set_sae_password(struct brcmf_if *ifp, const u8 *pwd_data,
>                                   u16 pwd_len)
>  {
> -       struct brcmf_pub *drvr = ifp->drvr;
> -       struct brcmf_wsec_sae_pwd_le sae_pwd;
> -       int err;
> -
> -       if (pwd_len > BRCMF_WSEC_MAX_SAE_PASSWORD_LEN) {
> -               bphy_err(drvr, "sae_password must be less than %d\n",
> -                        BRCMF_WSEC_MAX_SAE_PASSWORD_LEN);
> -               return -EINVAL;
> -       }
> -
> -       sae_pwd.key_len = cpu_to_le16(pwd_len);
> -       memcpy(sae_pwd.key, pwd_data, pwd_len);
> -
> -       err = brcmf_fil_iovar_data_set(ifp, "sae_password", &sae_pwd,
> -                                      sizeof(sae_pwd));
> -       if (err < 0)
> -               bphy_err(drvr, "failed to set SAE password in firmware (len=%u)\n",
> -                        pwd_len);
> -
> -       return err;
> +       return brcmf_set_wsec(ifp, pwd_data, pwd_len, BRCMF_WSEC_PASSPHRASE);
>  }
>
>  static void brcmf_link_down(struct brcmf_cfg80211_vif *vif, u16 reason,
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
> index 611d1a6aabb9..b68c46caabe8 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
> @@ -584,7 +584,7 @@ struct brcmf_wsec_key_le {
>  struct brcmf_wsec_pmk_le {
>         __le16  key_len;
>         __le16  flags;
> -       u8 key[2 * BRCMF_WSEC_MAX_PSK_LEN + 1];
> +       u8 key[BRCMF_WSEC_MAX_SAE_PASSWORD_LEN];
>  };
>
>  /**
>
> ---
> base-commit: ffc253263a1375a65fa6c9f62a893e9767fbebfa
> change-id: 20231107-brcmfmac-wpa3-9e5f66e8be34
>
> Best regards,
> --
> Hector Martin <marcan@marcan.st>
>
>

Looks good to me.

Reviewed-by: Neal Gompa <neal@gompa.dev>



--
真実はいつも一つ！/ Always, there's only one truth!

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

[Kalle Valo]

Hector Martin <marcan@marcan.st> wrote:

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

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20231107-brcmfmac-wpa3-v1-1-4c7db8636680@marcan.st/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

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

[Arend Van Spriel]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@kernel.org> wrote:

> Hector Martin <marcan@marcan.st> wrote:
>
>> 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

> --
> https://patchwork.kernel.org/project/linux-wireless/patch/20231107-brcmfmac-wpa3-v1-1-4c7db8636680@marcan.st/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

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

[Kalle Valo]

Arend Van Spriel <arend.vanspriel@broadcom.com> writes:

> On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@kernel.org> wrote:
>
>> Hector Martin <marcan@marcan.st> wrote:
>>
>>> 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.

Ok, thanks for checking.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

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

[Hector Martin]

On 2023/12/19 17:52, Arend Van Spriel wrote:
> On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@kernel.org> wrote:
> 
>> Hector Martin <marcan@marcan.st> wrote:
>>
>>> 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.

- Hector

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

[Arend van Spriel]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

On 12/19/2023 12:01 PM, Hector Martin wrote:
> 
> 
> On 2023/12/19 17:52, Arend Van Spriel wrote:
>> On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@kernel.org> wrote:
>>
>>> Hector Martin <marcan@marcan.st> wrote:
>>>
>>>> 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.

Regards,
Arend

Regards,
Arend

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

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

[Julian Calaby]

Hi Arend and Kalle,

On Wed, Dec 20, 2023 at 12:47 AM Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
>
> On 12/19/2023 12:01 PM, Hector Martin wrote:
> >
> >
> > On 2023/12/19 17:52, Arend Van Spriel wrote:
> >> On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@kernel.org> wrote:
> >>
> >>> Hector Martin <marcan@marcan.st> wrote:
> >>>
> >>>> 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.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

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

[Kalle Valo]

Daniel Berlin <dberlin@dberlin.org> writes:

> On Tue, Dec 19, 2023 at 7:46 AM Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
>
>  On 12/19/2023 12:01 PM, Hector Martin wrote:
>  > 
>  > 
>  > On 2023/12/19 17:52, Arend Van Spriel wrote:
>  >> On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@kernel.org> wrote:
>  >>
>  >>> Hector Martin <marcan@marcan.st> wrote:
>  >>>
>  >>>> 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.
>
> None of this refutes what he said
>
> We already know it doesn't work for the rpi3/4 users because they are
> blogging about it. The fact that you (not personally but as a
> maintainer) don't know what works for who or doesn't is part of the
> issue. Who are the users who this is for, how are you getting feedback
> on what is working or not, how are you testing that it stays working?
>
> I'm with Hector - this approach has mainly resulted in a driver that
> kind of works for some people with no rhyme or reason - but nobody
> knows who and what works for them. This isn't sustainable. You need
> testing and feedback loops from some defined populations.
>
> Of course, This will all become moot as we argue about it - more and
> more is breaking for more and more people (for example, management
> frames are totally broken on newer chips because we silently assume
> version 1).
>
> The driver is about one real upgrade cycle away from not working, in
> current form, for the vast majority of its users.
>
> One would hope we don't sit and argue about how to support the future
> while waiting for that to happen, instead we should be moving the
> driver forward. If we need to worry about specific older chip users,
> we should name who they are, how many there are, and what the limits
> of support are. We should then talk about the best way to support them
> while still moving the world forward.

Why is it that every patch Hector submits seems to end up with flame
wars? Look, we have a lot to do and please understand that our time is
limited. PLEASE listen to the review feedback and try to fix the patches
for the next review round, so that we can get this patch applied and
move forward.

And also these "we know better than you do" comments from people who
clearly are not really familiar with Linux wireless project, or even
kernel development, are not helping. Especially if it's in an HTML mail
(which our lists automatically drop).

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

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

[Hector Martin]

On 2023/12/19 23:42, Kalle Valo wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
>> On Tue, Dec 19, 2023 at 7:46 AM Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
>>
>>  On 12/19/2023 12:01 PM, Hector Martin wrote:
>>  > 
>>  > 
>>  > On 2023/12/19 17:52, Arend Van Spriel wrote:
>>  >> On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@kernel.org> wrote:
>>  >>
>>  >>> Hector Martin <marcan@marcan.st> wrote:
>>  >>>
>>  >>>> 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.
>>
>> None of this refutes what he said
>>
>> We already know it doesn't work for the rpi3/4 users because they are
>> blogging about it. The fact that you (not personally but as a
>> maintainer) don't know what works for who or doesn't is part of the
>> issue. Who are the users who this is for, how are you getting feedback
>> on what is working or not, how are you testing that it stays working?
>>
>> I'm with Hector - this approach has mainly resulted in a driver that
>> kind of works for some people with no rhyme or reason - but nobody
>> knows who and what works for them. This isn't sustainable. You need
>> testing and feedback loops from some defined populations.
>>
>> Of course, This will all become moot as we argue about it - more and
>> more is breaking for more and more people (for example, management
>> frames are totally broken on newer chips because we silently assume
>> version 1).
>>
>> The driver is about one real upgrade cycle away from not working, in
>> current form, for the vast majority of its users.
>>
>> One would hope we don't sit and argue about how to support the future
>> while waiting for that to happen, instead we should be moving the
>> driver forward. If we need to worry about specific older chip users,
>> we should name who they are, how many there are, and what the limits
>> of support are. We should then talk about the best way to support them
>> while still moving the world forward.
> 
> Why is it that every patch Hector submits seems to end up with flame
> wars?

Perhaps because this driver has approximately 0.1 direct maintainers
right now whose contributions are largely hem and hawing about things
without providing any real sustainable solutions, and your amazing
additions as the Wireless upstream maintainer have been things like
nitpicking whether or not I should use "v2:" in commit messages.

Just recently a patch was posted to remove the Infineon list from
MAINTAINERS because that company cares so little they have literally
stopped accepting emails from us. Meanwhile they are telling their
customers that they do not recommend upstream brcmfmac and they should
use their downstream driver [1].

As a reminder, the last patch authored by the sole (barely) active
maintainer of this driver was almost a year ago. The other two Broadcom
folks in MAINTAINERS haven't done anything in years. Arend himself has
admitted he only gets 20% time to work on this and it never actually
reaches anywhere near 20%.

Meanwhile Daniel here has been revamping large chunks of the driver
downstream, and fixing major longstanding issues with an intent to
upstream. But apparently his opinion doesn't matter.

Hey Linus, you have an M2 MacBook Air, right? I assume you want WiFi to
work on it properly upstream some day. With the dismal state of brcmfmac
maintainership, and with the disdain the people involved have for the
people *actually* doing the work on the driver and trying to get
everything upstream, that is never going to happen at this rate. Care to
chime in?

As far as I'm concerned, Cypress support should be ifdeffed out behind a
Kconfig flag marked BROKEN. If someone cares about it, they better step
up to maintain it and actually test things. We can't have companies
submitting device support patches and then checking out and abandoning
them and expect the remaining people actually working on the driver to
tiptoe around their code "just in case we break them" with no way to
actually test anything or properly support those chips. Even the
Raspberry Pi folks have been silent other than some empty words and no
actual action, so far. You'd think they'd care a bit more about shipping
hardware with zero actual upstream maintainer support, but apparently
they don't.

[1]
https://community.infineon.com/t5/AIROC-Wi-Fi-and-Wi-Fi-Bluetooth/Queries-re-linux-in-tree-driver-for-Infineon-Wifi-BT-controllers/td-p/354857

- Hector

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

[Linus Torvalds]

On Tue, 19 Dec 2023 at 16:06, Hector Martin <marcan@marcan.st> wrote:
>
> On 2023/12/19 23:42, Kalle Valo wrote:
> >
> > Why is it that every patch Hector submits seems to end up with flame
> > wars?

Well, I do think some of it is Hector's personality and forceful
approaches, but I do think part of it is also the area in question.

Because I do agree with Hector that..

> Just recently a patch was posted to remove the Infineon list from
> MAINTAINERS because that company cares so little they have literally
> stopped accepting emails from us. Meanwhile they are telling their
> customers that they do not recommend upstream brcmfmac and they should
> use their downstream driver [1].

Unquestionably broadcom is not helping maintain things, and I think it
should matter.

As Hector says, they point to their random driver dumps on their site
that you can't even download unless you are a "Broadcom community
member" or whatever, and hey - any company that works that way should
be seen as pretty much hostile to any actual maintenance and proper
development.

If Daniel and Hector are responsive to actual problem reports for the
changes they cause, I do think that should count a lot.

I don't think Cypress support should necessarily be removed (or marked
broken), but if the sae_password code already doesn't work, _that_
part certainly shouldn't hold things up?

Put another way: if we effectively don't have a driver maintainer that
can test things, and somebody is willing to step up, shouldn't we take
that person up on it?

                  Linus

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

[Hector Martin]

On 2023/12/20 10:44, Linus Torvalds wrote:
> On Tue, 19 Dec 2023 at 16:06, Hector Martin <marcan@marcan.st> wrote:
>>
>> On 2023/12/19 23:42, Kalle Valo wrote:
>>>
>>> Why is it that every patch Hector submits seems to end up with flame
>>> wars?
> 
> Well, I do think some of it is Hector's personality and forceful
> approaches, but I do think part of it is also the area in question.
> 
> Because I do agree with Hector that..
> 
>> Just recently a patch was posted to remove the Infineon list from
>> MAINTAINERS because that company cares so little they have literally
>> stopped accepting emails from us. Meanwhile they are telling their
>> customers that they do not recommend upstream brcmfmac and they should
>> use their downstream driver [1].
> 
> Unquestionably broadcom is not helping maintain things, and I think it
> should matter.
> 
> As Hector says, they point to their random driver dumps on their site
> that you can't even download unless you are a "Broadcom community
> member" or whatever, and hey - any company that works that way should
> be seen as pretty much hostile to any actual maintenance and proper
> development.
> 
> If Daniel and Hector are responsive to actual problem reports for the
> changes they cause, I do think that should count a lot.

Of course we're happy to do that. If this change goes in and we get an
actual report of breakage from someone, we'll have learned some very
valuable information: That there is, in fact, an end-user use case
(hardware/firmware/AP setting combination) where this code functions and
matters, and perhaps we'll have found someone willing to test things in
the future. Then we revert and rework the patch to keep the old code
path alive in that case.

The report will also give us valuable information about how to condition
it, because e.g. right now we don't even know if the sae_password code
works on any Cypress chips/firmwares at all, or conversely whether the
new WSEC code rather makes things work on some subset of Cypress
chips/firmwares instead. It is largely a mystery to everyone outside of
Broadcom and Cypress how that whole corporate division fork worked and
when and how the firmwares started diverging (never mind how Apple's
Broadcom firmwares may themselves differ).

It's the "don't touch it just in case" approach that is not sustainable,
because then we'll just be accumulating technical debt without the
slightest clue whether it even does anything useful or not, and
needlessly setting back development on the other and newer chips.

All this would, of course, be much easier if the vendor actually replied
to our emails, since evidently they know what chips/firmware branches
might have support for this, but even before Cypress names got removed
from MAINTAINERS I was already getting radio silence from them when I
asked questions like this, and even on the Broadcom side I had trouble
getting Arend to answer simple questions. Ultimately, with minimal to no
vendor cooperation, this driver becomes a reverse engineered, community
supported driver, with the inevitable gaps in testing and support that
entails when we don't have the information the manufacturers do, and
people need to understand the consequences of that. If the manufacturers
aren't stepping up to do their job, other members of the community (or
customers of those vendors) need to do so if there are hardware
configurations they rely on, because Daniel and I can't sign up to
proactively maintain and test every single Broadcom and Cypress/Infineon
chip out there. We don't have the hardware, nor do we have that kind of
bandwidth/time. Support for hardware that no maintainer/developer is
proactively testing will necessarily fall back to being reactive to
regression reports.

> I don't think Cypress support should necessarily be removed (or marked
> broken), but if the sae_password code already doesn't work, _that_
> part certainly shouldn't hold things up?
> 
> Put another way: if we effectively don't have a driver maintainer that
> can test things, and somebody is willing to step up, shouldn't we take
> that person up on it?

Personally, I do think the rPi folks themselves should step up for
*testing* at the very least. I did point them at our downstream WiFi
branch at one point during a previous discussion and haven't heard back,
so either they never tested it, or they did and it didn't break
anything. If they're shipping popular Linux hardware where the WiFi
chipset vendor has fully and completely checked out of any upstream
support, they need to either accept that upstream support will likely
break at some point (because that's just what happens when nobody cares
about a given piece of hardware, especially with drivers shared across
others like this one) or they need to proactively step up and take on,
minimally, an early testing role themselves.

- Hector

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

[Paul Fertser]

Hey Hector,

On Tue, Nov 07, 2023 at 03:05:31PM +0900, Hector Martin wrote:
> 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.

I'm sorry to disappoint you but I've just tested this patch on a
"Pinebook Pro" which has AP6255 module and it broke WPA3 Personal.

No error messages are emitted to the kernel log, just iwctl saying it
can't establish connection.

This is using "Cypress" firmware from the Linux firmware tree [0]
renamed to "brcmfmac43455-sdio.bin" which has the following features
(extracted from last two lines):

43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.234 (4ca95bb CY) CRC: 212e223d Date: Thu 2021-04-15 03:06:00 PDT Ucode Ver: 1043.2161 FWID 01-996384e2
DVID 01-1fda2915


This module is used on many SBCs, including some RaspberryPi
boards. The reason RaspberryPi owners complain about lack of WPA3
Personal support is that most of them are using obscure downstream
distros which ship brcmfmac firmware from somewhere else rather than
the Linux firmware tree, so they lack the "sae" feature. Another is
that it only works with iwd while default is wpa_supplicant.

So far all known reports of those who tried the right firmware on
RaspberryPi boards confirm WPA3 Personal was working with iwd [1].


I'll be happy to do more testing if needed. Thank you very much for
your hard and insightful work!


[0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/cypress/cyfmac43455-sdio.bin
[1] https://github.com/raspberrypi/linux/issues/4718#issuecomment-1279951709

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

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

[Kalle Valo]

Linus Torvalds <torvalds@linux-foundation.org> writes:

>> Just recently a patch was posted to remove the Infineon list from
>> MAINTAINERS because that company cares so little they have literally
>> stopped accepting emails from us. Meanwhile they are telling their
>> customers that they do not recommend upstream brcmfmac and they should
>> use their downstream driver [1].
>
> Unquestionably broadcom is not helping maintain things, and I think it
> should matter.
>
> As Hector says, they point to their random driver dumps on their site
> that you can't even download unless you are a "Broadcom community
> member" or whatever, and hey - any company that works that way should
> be seen as pretty much hostile to any actual maintenance and proper
> development.

Sadly this is the normal in the wireless world. All vendors focus on the
latest generation, currently it's Wi-Fi 7, and lose interest on older
generations. And vendors lose focus on the upstream drivers even faster,
usually after a customer project ends.

So in practise what we try to do is keep the drivers working somehow on
our own, even after the vendors are long gone. If we would deliberately
allow breaking drivers because vendor/corporations don't support us, I
suspect we would have sevaral broken drivers in upstream.

> If Daniel and Hector are responsive to actual problem reports for the
> changes they cause, I do think that should count a lot.

Sure, but they could also respect to the review comments. I find Arend's
proposal is reasonable and that's what I would implement in v2. We
(linux-wireless) make abstractions to workaround firmware problems or
interface conflicts all the time, just look at ath10k for example. I
would not be surprised if we need to add even more abstractions to
brcmfmac in the future. And Arend is the expert here, he has best
knowledge of Broadcom devices and I trust him.

Has anyone even investigated what it would need to implement Arend's
proposal? At least I don't see any indication of that.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

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

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On Wed, Dec 20, 2023 at 01:16:20PM +0900, Hector Martin wrote:
> 
> 
> On 2023/12/20 10:44, Linus Torvalds wrote:
> > Put another way: if we effectively don't have a driver maintainer that
> > can test things, and somebody is willing to step up, shouldn't we take
> > that person up on it?
> 
> Personally, I do think the rPi folks themselves should step up for
> *testing* at the very least. I did point them at our downstream WiFi
> branch at one point during a previous discussion and haven't heard back,
> so either they never tested it, or they did and it didn't break
> anything. If they're shipping popular Linux hardware where the WiFi
> chipset vendor has fully and completely checked out of any upstream
> support, they need to either accept that upstream support will likely
> break at some point (because that's just what happens when nobody cares
> about a given piece of hardware, especially with drivers shared across
> others like this one) or they need to proactively step up and take on,
> minimally, an early testing role themselves.

I'm agree that downstream (e.g. rPi) developers should also participating
in upstream kernel development.

Also Cc: rPi folks to solicit their opinions.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Eric Curtin]

On Wed, 20 Dec 2023 at 01:54, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, 19 Dec 2023 at 16:06, Hector Martin <marcan@marcan.st> wrote:
> >
> > On 2023/12/19 23:42, Kalle Valo wrote:
> > >
> > > Why is it that every patch Hector submits seems to end up with flame
> > > wars?
>
> Well, I do think some of it is Hector's personality and forceful
> approaches, but I do think part of it is also the area in question.
>
> Because I do agree with Hector that..
>
> > Just recently a patch was posted to remove the Infineon list from
> > MAINTAINERS because that company cares so little they have literally
> > stopped accepting emails from us. Meanwhile they are telling their
> > customers that they do not recommend upstream brcmfmac and they should
> > use their downstream driver [1].
>
> Unquestionably broadcom is not helping maintain things, and I think it
> should matter.
>
> As Hector says, they point to their random driver dumps on their site
> that you can't even download unless you are a "Broadcom community
> member" or whatever, and hey - any company that works that way should
> be seen as pretty much hostile to any actual maintenance and proper
> development.
>
> If Daniel and Hector are responsive to actual problem reports for the
> changes they cause, I do think that should count a lot.
>
> I don't think Cypress support should necessarily be removed (or marked
> broken), but if the sae_password code already doesn't work, _that_
> part certainly shouldn't hold things up?
>
> Put another way: if we effectively don't have a driver maintainer that
> can test things, and somebody is willing to step up, shouldn't we take
> that person up on it?

I am trying to help try and find a maintainer in the community, but of
course I can't guarantee anything. Theoretically of course it should
be someone from Broadcom, Raspberry Pi, etc. and not the community
(not that this helps unblock us promptly).

I just would like to say this upstream Cypress driver has a large
number of users via Fedora and CentOS Stream Automotive Distribution.
And that's just the Fedora family of distros. But the Apple Silicon
devices have a pretty large amount of users also.

We need to find a way of accommodating both. If that's either fork the
code into two separate files somehow or find another maintainer, I
don't know (just my uninformed opinion).

Is mise le meas/Regards,

Eric Curtin

>
>                   Linus
>

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

[Kalle Valo]

Kalle Valo <kvalo@kernel.org> writes:

> And Arend is the expert here, he has best knowledge of Broadcom
> devices and I trust him.

But Arend decided to step down:

https://patchwork.kernel.org/project/linux-wireless/patch/20231220095750.307829-1-arend.vanspriel@broadcom.com/

And no wonder.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

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

[Eric Curtin]

On Wed, 20 Dec 2023 at 16:05, Kalle Valo <kvalo@kernel.org> wrote:
>
> Kalle Valo <kvalo@kernel.org> writes:
>
> > And Arend is the expert here, he has best knowledge of Broadcom
> > devices and I trust him.
>
> But Arend decided to step down:
>
> https://patchwork.kernel.org/project/linux-wireless/patch/20231220095750.307829-1-arend.vanspriel@broadcom.com/
>
> And no wonder.

By the way, just in case my earlier email was misinterpreted, when I
suggested we find another maintainer, I meant a co-maintainer to help
spread the load, test, review, etc.

I'm sad Arend stepped down and that we have less maintainers now. I
meant it in good spirits.

I have received messages from almost 100 people that seem interested
in helping integrate Broadcom wifi in the upstream kernel. I have
asked them kindly to not pollute the mailing list and to read this
thread to get full context.

Is mise le meas/Regards,

Eric Curtin

>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>

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

[Hector Martin]

On 2023/12/20 19:16, Paul Fertser wrote:
> Hey Hector,
> 
> On Tue, Nov 07, 2023 at 03:05:31PM +0900, Hector Martin wrote:
>> 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.
> 
> I'm sorry to disappoint you but I've just tested this patch on a
> "Pinebook Pro" which has AP6255 module and it broke WPA3 Personal.
> 
> No error messages are emitted to the kernel log, just iwctl saying it
> can't establish connection.
> 
> This is using "Cypress" firmware from the Linux firmware tree [0]
> renamed to "brcmfmac43455-sdio.bin" which has the following features
> (extracted from last two lines):
> 
> 43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.234 (4ca95bb CY) CRC: 212e223d Date: Thu 2021-04-15 03:06:00 PDT Ucode Ver: 1043.2161 FWID 01-996384e2
> DVID 01-1fda2915
> 
> 
> This module is used on many SBCs, including some RaspberryPi
> boards. The reason RaspberryPi owners complain about lack of WPA3
> Personal support is that most of them are using obscure downstream
> distros which ship brcmfmac firmware from somewhere else rather than
> the Linux firmware tree, so they lack the "sae" feature. Another is
> that it only works with iwd while default is wpa_supplicant.
> 
> So far all known reports of those who tried the right firmware on
> RaspberryPi boards confirm WPA3 Personal was working with iwd [1].
> 
> 
> I'll be happy to do more testing if needed. Thank you very much for
> your hard and insightful work!

Thank you for being the first person to actually test any of this :)

Now we actually have a reason to keep the code. The next thing I wonder
is whether any of the *other* Cypress chips will respond to WSEC (in
addition to or instead of sae_password)...

Are you willing to test all the other wifi stuff we have queued up
downstream? There's a whole pile of changes here:

https://github.com/AsahiLinux/linux/commits/bits/080-wifi/

If things break it would be very helpful if you could bisect it down to
the specific commit. This patch is also in there of course, feel free to
revert/rebase it out.

- Hector

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

[Hector Martin]

On 2023/12/20 19:20, Kalle Valo wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
>>> Just recently a patch was posted to remove the Infineon list from
>>> MAINTAINERS because that company cares so little they have literally
>>> stopped accepting emails from us. Meanwhile they are telling their
>>> customers that they do not recommend upstream brcmfmac and they should
>>> use their downstream driver [1].
>>
>> Unquestionably broadcom is not helping maintain things, and I think it
>> should matter.
>>
>> As Hector says, they point to their random driver dumps on their site
>> that you can't even download unless you are a "Broadcom community
>> member" or whatever, and hey - any company that works that way should
>> be seen as pretty much hostile to any actual maintenance and proper
>> development.
> 
> Sadly this is the normal in the wireless world. All vendors focus on the
> latest generation, currently it's Wi-Fi 7, and lose interest on older
> generations. And vendors lose focus on the upstream drivers even faster,
> usually after a customer project ends.
> 
> So in practise what we try to do is keep the drivers working somehow on
> our own, even after the vendors are long gone. If we would deliberately
> allow breaking drivers because vendor/corporations don't support us, I
> suspect we would have sevaral broken drivers in upstream.
> 
>> If Daniel and Hector are responsive to actual problem reports for the
>> changes they cause, I do think that should count a lot.
> 
> Sure, but they could also respect to the review comments. I find Arend's
> proposal is reasonable and that's what I would implement in v2. We
> (linux-wireless) make abstractions to workaround firmware problems or
> interface conflicts all the time, just look at ath10k for example. I
> would not be surprised if we need to add even more abstractions to
> brcmfmac in the future. And Arend is the expert here, he has best
> knowledge of Broadcom devices and I trust him.
> 
> Has anyone even investigated what it would need to implement Arend's
> proposal? At least I don't see any indication of that.

Of course we can implement it (and we will as we actually got a report
of this patch breaking Cypress now, finally).

The question was never whether it could be done, we're already doing a
bunch of abstractions to deal with just the Broadcom-only side of things
too. The point I was trying to make is that we need to *know* what
firmware abstractions we need and *why* they are needed. We can't just
say, for every change, "well, nobody knows if the existing code works or
not, so let's just add an abstraction just in case the change breaks
something". As far as anyone involved in the discussions until now could
tell, this code was just something some Cypress person dumped upstream,
and nobody involved was being responsive to any of our inquiries, so
there was no way to be certain it worked at all, whether it was
supported in public firmware, or anything else.

*Now* that we know the existing code is actually functional and not just
dead/broken, and that the WSEC approach is conversely not functional on
the Cypress firmwares, it makes sense to introduce an abstraction.

Here's an example of the case where an abstraction was *not* needed: I
switched over WPA PSK configuration from hex-encoded to binary. That was
needed to make more recent Apple firmwares work. My evidence at the time
that that change *was* at least fairly backwards compatible was that the
OpenBSD driver had been doing it that way all along. Had we introduced
an abstraction/conditional for that case "just in case", it would have
generated superfluous technical debt for no reason.

- Hector

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

[Arend van Spriel]

[-- Attachment #1: Type: text/plain, Size: 5029 bytes --]

On 12/20/2023 7:14 PM, Hector Martin wrote:
> 
> 
> On 2023/12/20 19:20, Kalle Valo wrote:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>>>> Just recently a patch was posted to remove the Infineon list from
>>>> MAINTAINERS because that company cares so little they have literally
>>>> stopped accepting emails from us. Meanwhile they are telling their
>>>> customers that they do not recommend upstream brcmfmac and they should
>>>> use their downstream driver [1].
>>>
>>> Unquestionably broadcom is not helping maintain things, and I think it
>>> should matter.
>>>
>>> As Hector says, they point to their random driver dumps on their site
>>> that you can't even download unless you are a "Broadcom community
>>> member" or whatever, and hey - any company that works that way should
>>> be seen as pretty much hostile to any actual maintenance and proper
>>> development.
>>
>> Sadly this is the normal in the wireless world. All vendors focus on the
>> latest generation, currently it's Wi-Fi 7, and lose interest on older
>> generations. And vendors lose focus on the upstream drivers even faster,
>> usually after a customer project ends.
>>
>> So in practise what we try to do is keep the drivers working somehow on
>> our own, even after the vendors are long gone. If we would deliberately
>> allow breaking drivers because vendor/corporations don't support us, I
>> suspect we would have sevaral broken drivers in upstream.
>>
>>> If Daniel and Hector are responsive to actual problem reports for the
>>> changes they cause, I do think that should count a lot.
>>
>> Sure, but they could also respect to the review comments. I find Arend's
>> proposal is reasonable and that's what I would implement in v2. We
>> (linux-wireless) make abstractions to workaround firmware problems or
>> interface conflicts all the time, just look at ath10k for example. I
>> would not be surprised if we need to add even more abstractions to
>> brcmfmac in the future. And Arend is the expert here, he has best
>> knowledge of Broadcom devices and I trust him.
>>
>> Has anyone even investigated what it would need to implement Arend's
>> proposal? At least I don't see any indication of that.
> 
> Of course we can implement it (and we will as we actually got a report
> of this patch breaking Cypress now, finally).
> 
> The question was never whether it could be done, we're already doing a
> bunch of abstractions to deal with just the Broadcom-only side of things
> too. The point I was trying to make is that we need to *know* what
> firmware abstractions we need and *why* they are needed. We can't just
> say, for every change, "well, nobody knows if the existing code works or
> not, so let's just add an abstraction just in case the change breaks
> something". As far as anyone involved in the discussions until now could
> tell, this code was just something some Cypress person dumped upstream,
> and nobody involved was being responsive to any of our inquiries, so
> there was no way to be certain it worked at all, whether it was
> supported in public firmware, or anything else.
> 
> *Now* that we know the existing code is actually functional and not just
> dead/broken, and that the WSEC approach is conversely not functional on
> the Cypress firmwares, it makes sense to introduce an abstraction.

Just a quick look in the git history could have told you that it was not 
just dumped upstream and at least one person was using it and extended 
it for 802.11r support (fast-roaming):


author	Paweł Drewniak <czajernia@gmail.com>	2021-08-24 23:13:30 +0100
committer	Kalle Valo <kvalo@codeaurora.org>	2021-08-29 11:33:07 +0300
commit	4b51de063d5310f1fb297388b7955926e63e45c9 (patch)
tree	ba2ccb5cbd055d482a8daa263f5e53531c07667f 
/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
parent	81f9ebd43659320a88cae8ed5124c50b4d47ab66 (diff)
download	wireless-4b51de063d5310f1fb297388b7955926e63e45c9.tar.gz
brcmfmac: Add WPA3 Personal with FT to supported cipher suites
This allows the driver to connect to BSSIDs supporting SAE with 802.11r.
Tested on Raspberry Pi 4 Model B (STA) and UniFi 6LR/OpenWRT 21.02.0-rc2.
AP was set to 'sae-mixed' (WPA2/3 Personal).

Signed-off-by: Paweł Drewniak <czajernia@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210824221330.3847139-1-czajernia@gmail.com

> Here's an example of the case where an abstraction was *not* needed: I
> switched over WPA PSK configuration from hex-encoded to binary. That was
> needed to make more recent Apple firmwares work. My evidence at the time
> that that change *was* at least fairly backwards compatible was that the
> OpenBSD driver had been doing it that way all along. Had we introduced
> an abstraction/conditional for that case "just in case", it would have
> generated superfluous technical debt for no reason.

Fully agreeing here and you already given the argument for that in the 
commit message. Hence there was no discussion whatsoever about that.

Regards,
Arend

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

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

[Hector Martin]

On 2023/12/21 4:36, Arend van Spriel wrote:
> On 12/20/2023 7:14 PM, Hector Martin wrote:
>>
>>
>> On 2023/12/20 19:20, Kalle Valo wrote:
>>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>>
>>>>> Just recently a patch was posted to remove the Infineon list from
>>>>> MAINTAINERS because that company cares so little they have literally
>>>>> stopped accepting emails from us. Meanwhile they are telling their
>>>>> customers that they do not recommend upstream brcmfmac and they should
>>>>> use their downstream driver [1].
>>>>
>>>> Unquestionably broadcom is not helping maintain things, and I think it
>>>> should matter.
>>>>
>>>> As Hector says, they point to their random driver dumps on their site
>>>> that you can't even download unless you are a "Broadcom community
>>>> member" or whatever, and hey - any company that works that way should
>>>> be seen as pretty much hostile to any actual maintenance and proper
>>>> development.
>>>
>>> Sadly this is the normal in the wireless world. All vendors focus on the
>>> latest generation, currently it's Wi-Fi 7, and lose interest on older
>>> generations. And vendors lose focus on the upstream drivers even faster,
>>> usually after a customer project ends.
>>>
>>> So in practise what we try to do is keep the drivers working somehow on
>>> our own, even after the vendors are long gone. If we would deliberately
>>> allow breaking drivers because vendor/corporations don't support us, I
>>> suspect we would have sevaral broken drivers in upstream.
>>>
>>>> If Daniel and Hector are responsive to actual problem reports for the
>>>> changes they cause, I do think that should count a lot.
>>>
>>> Sure, but they could also respect to the review comments. I find Arend's
>>> proposal is reasonable and that's what I would implement in v2. We
>>> (linux-wireless) make abstractions to workaround firmware problems or
>>> interface conflicts all the time, just look at ath10k for example. I
>>> would not be surprised if we need to add even more abstractions to
>>> brcmfmac in the future. And Arend is the expert here, he has best
>>> knowledge of Broadcom devices and I trust him.
>>>
>>> Has anyone even investigated what it would need to implement Arend's
>>> proposal? At least I don't see any indication of that.
>>
>> Of course we can implement it (and we will as we actually got a report
>> of this patch breaking Cypress now, finally).
>>
>> The question was never whether it could be done, we're already doing a
>> bunch of abstractions to deal with just the Broadcom-only side of things
>> too. The point I was trying to make is that we need to *know* what
>> firmware abstractions we need and *why* they are needed. We can't just
>> say, for every change, "well, nobody knows if the existing code works or
>> not, so let's just add an abstraction just in case the change breaks
>> something". As far as anyone involved in the discussions until now could
>> tell, this code was just something some Cypress person dumped upstream,
>> and nobody involved was being responsive to any of our inquiries, so
>> there was no way to be certain it worked at all, whether it was
>> supported in public firmware, or anything else.
>>
>> *Now* that we know the existing code is actually functional and not just
>> dead/broken, and that the WSEC approach is conversely not functional on
>> the Cypress firmwares, it makes sense to introduce an abstraction.
> 
> Just a quick look in the git history could have told you that it was not 
> just dumped upstream and at least one person was using it and extended 
> it for 802.11r support (fast-roaming):
> 
> 
> author	Paweł Drewniak <czajernia@gmail.com>	2021-08-24 23:13:30 +0100
> committer	Kalle Valo <kvalo@codeaurora.org>	2021-08-29 11:33:07 +0300
> commit	4b51de063d5310f1fb297388b7955926e63e45c9 (patch)
> tree	ba2ccb5cbd055d482a8daa263f5e53531c07667f 
> /drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> parent	81f9ebd43659320a88cae8ed5124c50b4d47ab66 (diff)
> download	wireless-4b51de063d5310f1fb297388b7955926e63e45c9.tar.gz
> brcmfmac: Add WPA3 Personal with FT to supported cipher suites
> This allows the driver to connect to BSSIDs supporting SAE with 802.11r.
> Tested on Raspberry Pi 4 Model B (STA) and UniFi 6LR/OpenWRT 21.02.0-rc2.
> AP was set to 'sae-mixed' (WPA2/3 Personal).
> 
> Signed-off-by: Paweł Drewniak <czajernia@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> Link: https://lore.kernel.org/r/20210824221330.3847139-1-czajernia@gmail.com

Sure, but we also had user reports of it *not* actually working (maybe
it regressed?). We didn't know whether it was functional with the
linux-firmware blobs in any way, I wanted confirmation of that. And we
also didn't know that the patch *would* break it at all; perhaps the
Cypress firmware had also grown support for the WSEC mechanism.

That's why I wanted someone to actually confirm the code worked (in some
subset of cases) and the patch didn't, before starting to introduce
conditionals. There is, of course, also the element that the Cypress
side has been long unmaintained, and if nobody is testing/giving
feedback/complaining, perhaps it's better to err on the side of maybe
breaking something and see if that gets someone to come out of the
woodwork if it really breaks, rather than tiptoeing around the code
without knowing what's going on and without anyone actually testing things.

It's not about this *specific* patch, it's about the general situation
of not being able to touch firmware interfaces "just in case Cypress
breaks" being unsustainable in the long term. I wasn't pushing back
because I think this particular one will be hard, I was pushing back
because I can read the tea leaves and see this is not going to end well
if it's the approach we start taking for everything. We *need* someone
to be testing patches on Cypress, we can't just "try not to touch it"
and cross our fingers. That just ends in disaster, we are not going to
succeed in not breaking it either way and it's going to make the driver
worse.

- Hector

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

[Arend van Spriel]

[-- Attachment #1: Type: text/plain, Size: 7902 bytes --]

- SHA-cyfmac-dev-list@infineon.com

On 12/21/2023 1:49 AM, Hector Martin wrote:
> 
> 
> On 2023/12/21 4:36, Arend van Spriel wrote:
>> On 12/20/2023 7:14 PM, Hector Martin wrote:
>>>
>>>
>>> On 2023/12/20 19:20, Kalle Valo wrote:
>>>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>>>
>>>>>> Just recently a patch was posted to remove the Infineon list from
>>>>>> MAINTAINERS because that company cares so little they have literally
>>>>>> stopped accepting emails from us. Meanwhile they are telling their
>>>>>> customers that they do not recommend upstream brcmfmac and they should
>>>>>> use their downstream driver [1].
>>>>>
>>>>> Unquestionably broadcom is not helping maintain things, and I think it
>>>>> should matter.
>>>>>
>>>>> As Hector says, they point to their random driver dumps on their site
>>>>> that you can't even download unless you are a "Broadcom community
>>>>> member" or whatever, and hey - any company that works that way should
>>>>> be seen as pretty much hostile to any actual maintenance and proper
>>>>> development.
>>>>
>>>> Sadly this is the normal in the wireless world. All vendors focus on the
>>>> latest generation, currently it's Wi-Fi 7, and lose interest on older
>>>> generations. And vendors lose focus on the upstream drivers even faster,
>>>> usually after a customer project ends.
>>>>
>>>> So in practise what we try to do is keep the drivers working somehow on
>>>> our own, even after the vendors are long gone. If we would deliberately
>>>> allow breaking drivers because vendor/corporations don't support us, I
>>>> suspect we would have sevaral broken drivers in upstream.
>>>>
>>>>> If Daniel and Hector are responsive to actual problem reports for the
>>>>> changes they cause, I do think that should count a lot.
>>>>
>>>> Sure, but they could also respect to the review comments. I find Arend's
>>>> proposal is reasonable and that's what I would implement in v2. We
>>>> (linux-wireless) make abstractions to workaround firmware problems or
>>>> interface conflicts all the time, just look at ath10k for example. I
>>>> would not be surprised if we need to add even more abstractions to
>>>> brcmfmac in the future. And Arend is the expert here, he has best
>>>> knowledge of Broadcom devices and I trust him.
>>>>
>>>> Has anyone even investigated what it would need to implement Arend's
>>>> proposal? At least I don't see any indication of that.
>>>
>>> Of course we can implement it (and we will as we actually got a report
>>> of this patch breaking Cypress now, finally).
>>>
>>> The question was never whether it could be done, we're already doing a
>>> bunch of abstractions to deal with just the Broadcom-only side of things
>>> too. The point I was trying to make is that we need to *know* what
>>> firmware abstractions we need and *why* they are needed. We can't just
>>> say, for every change, "well, nobody knows if the existing code works or
>>> not, so let's just add an abstraction just in case the change breaks
>>> something". As far as anyone involved in the discussions until now could
>>> tell, this code was just something some Cypress person dumped upstream,
>>> and nobody involved was being responsive to any of our inquiries, so
>>> there was no way to be certain it worked at all, whether it was
>>> supported in public firmware, or anything else.
>>>
>>> *Now* that we know the existing code is actually functional and not just
>>> dead/broken, and that the WSEC approach is conversely not functional on
>>> the Cypress firmwares, it makes sense to introduce an abstraction.
>>
>> Just a quick look in the git history could have told you that it was not
>> just dumped upstream and at least one person was using it and extended
>> it for 802.11r support (fast-roaming):
>>
>>
>> author	Paweł Drewniak <czajernia@gmail.com>	2021-08-24 23:13:30 +0100
>> committer	Kalle Valo <kvalo@codeaurora.org>	2021-08-29 11:33:07 +0300
>> commit	4b51de063d5310f1fb297388b7955926e63e45c9 (patch)
>> tree	ba2ccb5cbd055d482a8daa263f5e53531c07667f
>> /drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> parent	81f9ebd43659320a88cae8ed5124c50b4d47ab66 (diff)
>> download	wireless-4b51de063d5310f1fb297388b7955926e63e45c9.tar.gz
>> brcmfmac: Add WPA3 Personal with FT to supported cipher suites
>> This allows the driver to connect to BSSIDs supporting SAE with 802.11r.
>> Tested on Raspberry Pi 4 Model B (STA) and UniFi 6LR/OpenWRT 21.02.0-rc2.
>> AP was set to 'sae-mixed' (WPA2/3 Personal).
>>
>> Signed-off-by: Paweł Drewniak <czajernia@gmail.com>
>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>> Link: https://lore.kernel.org/r/20210824221330.3847139-1-czajernia@gmail.com
> 
> Sure, but we also had user reports of it *not* actually working (maybe
> it regressed?). We didn't know whether it was functional with the
> linux-firmware blobs in any way, I wanted confirmation of that. And we
> also didn't know that the patch *would* break it at all; perhaps the
> Cypress firmware had also grown support for the WSEC mechanism.
> 
> That's why I wanted someone to actually confirm the code worked (in some
> subset of cases) and the patch didn't, before starting to introduce
> conditionals. There is, of course, also the element that the Cypress
> side has been long unmaintained, and if nobody is testing/giving
> feedback/complaining, perhaps it's better to err on the side of maybe
> breaking something and see if that gets someone to come out of the
> woodwork if it really breaks, rather than tiptoeing around the code
> without knowing what's going on and without anyone actually testing things.

That is because you distrust the intent that Cypress was really 
contributing. They were and I trusted them to not just throw in a 
feature like WPA3. When Infineon took over they went mute. Upon 
reviewing your patch (again) I also sent an email to them asking 
specifically about the status of the sae_password interface. I did not 
use the mailing list which indeed bounces these days (hence removed 
them) but the last living soul that I had contact with about a year ago 
whether they were still comitted to be involved. I guess out of 
politeness or embarrassment I got confirmation they were and never heard 
from him again. The query about the sae_password interface is still pending.

> It's not about this *specific* patch, it's about the general situation
> of not being able to touch firmware interfaces "just in case Cypress
> breaks" being unsustainable in the long term. I wasn't pushing back
> because I think this particular one will be hard, I was pushing back
> because I can read the tea leaves and see this is not going to end well
> if it's the approach we start taking for everything. We *need* someone
> to be testing patches on Cypress, we can't just "try not to touch it"
> and cross our fingers. That just ends in disaster, we are not going to
> succeed in not breaking it either way and it's going to make the driver
> worse.

I admire you ability of reading tea leaves. You saw the Grim I reckon. 
Admittedly your responses on every comment from my side (or Kalle for 
that matter) was polarizing every discussion. That is common way people 
treat each other nowadays especially online where a conversation is just 
a pile of text going shit. It does not bring out the best in me either, 
but it was draining every ounce of energy from me so better end it by 
stepping out.

I added the ground work for multi-vendor support, but have not decided 
on the approach to take. Abstract per firmware interface primitive or 
simply have a cfg80211.c and fwil_types.h per vendor OR implement a 
vendor-specific cfg80211 callback and override the default callback 
during the driver attach, ie. in brcmf_fwvid_wcc_attach(). The latter 
duplicates things, but lean towards that as it may be easier on the 
long-term. What do your tea leaves tell you ;-)

Regards,
Arend


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

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

[Marcel Holtmann]

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

Regards

Marcel

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

[Neal Gompa]

On Thu, Dec 21, 2023 at 3:40 PM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> 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@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



--
真実はいつも一つ！/ Always, there's only one truth!

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

[Hector Martin]

On 2023/12/21 18:57, Arend van Spriel wrote:
> - SHA-cyfmac-dev-list@infineon.com
> 
> On 12/21/2023 1:49 AM, Hector Martin wrote:
>>
>>
>> On 2023/12/21 4:36, Arend van Spriel wrote:
>>> On 12/20/2023 7:14 PM, Hector Martin wrote:
>>>>
>>>>
>>>> On 2023/12/20 19:20, Kalle Valo wrote:
>>>>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>>>>
>>>>>>> Just recently a patch was posted to remove the Infineon list from
>>>>>>> MAINTAINERS because that company cares so little they have literally
>>>>>>> stopped accepting emails from us. Meanwhile they are telling their
>>>>>>> customers that they do not recommend upstream brcmfmac and they should
>>>>>>> use their downstream driver [1].
>>>>>>
>>>>>> Unquestionably broadcom is not helping maintain things, and I think it
>>>>>> should matter.
>>>>>>
>>>>>> As Hector says, they point to their random driver dumps on their site
>>>>>> that you can't even download unless you are a "Broadcom community
>>>>>> member" or whatever, and hey - any company that works that way should
>>>>>> be seen as pretty much hostile to any actual maintenance and proper
>>>>>> development.
>>>>>
>>>>> Sadly this is the normal in the wireless world. All vendors focus on the
>>>>> latest generation, currently it's Wi-Fi 7, and lose interest on older
>>>>> generations. And vendors lose focus on the upstream drivers even faster,
>>>>> usually after a customer project ends.
>>>>>
>>>>> So in practise what we try to do is keep the drivers working somehow on
>>>>> our own, even after the vendors are long gone. If we would deliberately
>>>>> allow breaking drivers because vendor/corporations don't support us, I
>>>>> suspect we would have sevaral broken drivers in upstream.
>>>>>
>>>>>> If Daniel and Hector are responsive to actual problem reports for the
>>>>>> changes they cause, I do think that should count a lot.
>>>>>
>>>>> Sure, but they could also respect to the review comments. I find Arend's
>>>>> proposal is reasonable and that's what I would implement in v2. We
>>>>> (linux-wireless) make abstractions to workaround firmware problems or
>>>>> interface conflicts all the time, just look at ath10k for example. I
>>>>> would not be surprised if we need to add even more abstractions to
>>>>> brcmfmac in the future. And Arend is the expert here, he has best
>>>>> knowledge of Broadcom devices and I trust him.
>>>>>
>>>>> Has anyone even investigated what it would need to implement Arend's
>>>>> proposal? At least I don't see any indication of that.
>>>>
>>>> Of course we can implement it (and we will as we actually got a report
>>>> of this patch breaking Cypress now, finally).
>>>>
>>>> The question was never whether it could be done, we're already doing a
>>>> bunch of abstractions to deal with just the Broadcom-only side of things
>>>> too. The point I was trying to make is that we need to *know* what
>>>> firmware abstractions we need and *why* they are needed. We can't just
>>>> say, for every change, "well, nobody knows if the existing code works or
>>>> not, so let's just add an abstraction just in case the change breaks
>>>> something". As far as anyone involved in the discussions until now could
>>>> tell, this code was just something some Cypress person dumped upstream,
>>>> and nobody involved was being responsive to any of our inquiries, so
>>>> there was no way to be certain it worked at all, whether it was
>>>> supported in public firmware, or anything else.
>>>>
>>>> *Now* that we know the existing code is actually functional and not just
>>>> dead/broken, and that the WSEC approach is conversely not functional on
>>>> the Cypress firmwares, it makes sense to introduce an abstraction.
>>>
>>> Just a quick look in the git history could have told you that it was not
>>> just dumped upstream and at least one person was using it and extended
>>> it for 802.11r support (fast-roaming):
>>>
>>>
>>> author	Paweł Drewniak <czajernia@gmail.com>	2021-08-24 23:13:30 +0100
>>> committer	Kalle Valo <kvalo@codeaurora.org>	2021-08-29 11:33:07 +0300
>>> commit	4b51de063d5310f1fb297388b7955926e63e45c9 (patch)
>>> tree	ba2ccb5cbd055d482a8daa263f5e53531c07667f
>>> /drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> parent	81f9ebd43659320a88cae8ed5124c50b4d47ab66 (diff)
>>> download	wireless-4b51de063d5310f1fb297388b7955926e63e45c9.tar.gz
>>> brcmfmac: Add WPA3 Personal with FT to supported cipher suites
>>> This allows the driver to connect to BSSIDs supporting SAE with 802.11r.
>>> Tested on Raspberry Pi 4 Model B (STA) and UniFi 6LR/OpenWRT 21.02.0-rc2.
>>> AP was set to 'sae-mixed' (WPA2/3 Personal).
>>>
>>> Signed-off-by: Paweł Drewniak <czajernia@gmail.com>
>>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>>> Link: https://lore.kernel.org/r/20210824221330.3847139-1-czajernia@gmail.com
>>
>> Sure, but we also had user reports of it *not* actually working (maybe
>> it regressed?). We didn't know whether it was functional with the
>> linux-firmware blobs in any way, I wanted confirmation of that. And we
>> also didn't know that the patch *would* break it at all; perhaps the
>> Cypress firmware had also grown support for the WSEC mechanism.
>>
>> That's why I wanted someone to actually confirm the code worked (in some
>> subset of cases) and the patch didn't, before starting to introduce
>> conditionals. There is, of course, also the element that the Cypress
>> side has been long unmaintained, and if nobody is testing/giving
>> feedback/complaining, perhaps it's better to err on the side of maybe
>> breaking something and see if that gets someone to come out of the
>> woodwork if it really breaks, rather than tiptoeing around the code
>> without knowing what's going on and without anyone actually testing things.
> 
> That is because you distrust the intent that Cypress was really 
> contributing. They were and I trusted them to not just throw in a 
> feature like WPA3. When Infineon took over they went mute. Upon 
> reviewing your patch (again) I also sent an email to them asking 
> specifically about the status of the sae_password interface. I did not 
> use the mailing list which indeed bounces these days (hence removed 
> them) but the last living soul that I had contact with about a year ago 
> whether they were still comitted to be involved. I guess out of 
> politeness or embarrassment I got confirmation they were and never heard 
> from him again. The query about the sae_password interface is still pending.

If only corporate acquisition politics didn't repeatedly throw a wrench
into this one... :/

This is where we are though, Infineon clearly doesn't care, so it's time
to move on.

>> It's not about this *specific* patch, it's about the general situation
>> of not being able to touch firmware interfaces "just in case Cypress
>> breaks" being unsustainable in the long term. I wasn't pushing back
>> because I think this particular one will be hard, I was pushing back
>> because I can read the tea leaves and see this is not going to end well
>> if it's the approach we start taking for everything. We *need* someone
>> to be testing patches on Cypress, we can't just "try not to touch it"
>> and cross our fingers. That just ends in disaster, we are not going to
>> succeed in not breaking it either way and it's going to make the driver
>> worse.
> 
> I admire you ability of reading tea leaves. You saw the Grim I reckon. 
> Admittedly your responses on every comment from my side (or Kalle for 
> that matter) was polarizing every discussion. That is common way people 
> treat each other nowadays especially online where a conversation is just 
> a pile of text going shit. It does not bring out the best in me either, 
> but it was draining every ounce of energy from me so better end it by 
> stepping out.

The hilariously outdated kernel development model surely doesn't help
either (I've stated my opinion on this quite a few times if you've
followed around) ;)

This stuff gets *really* frustrating when you're trying to improve what
is, I hope we can all admit, an undermaintained driver (that is not to
say it's anyone's fault personally), and end up getting held back due to
everything from coding style nitpicks to people not having the time to
be responsive. It's just not helpful. It's important to know when to
step aside and let people actually get stuff done.

When Daniel started sending me brcmfmac patches downstream, I took a
look at a few of them, decided he knew what he was doing, and just
started pulling in his branches wholesale. Was it perfect? No, I had to
debug at least one regression at one point. But it took me less time to
do that than it would've to go through the commits with a fine toothed
comb, so it was clearly the right decision.

That is not to say that should be the standard upstream (we make a point
of moving fast and breaking things more downstream, since it's a proving
ground for what eventually will be upstreamed), but I think it does
demonstrate the kind of delegation ability that is sorely lacking in
many drivers and subsystems in the kernel these days. Maintainers become
entrenched in their position, long beyond the point where they have the
time/motivation/ability to drive the code forward, and end up in the way
of new people who are trying to make a difference. I think Linus knows
full well the kernel maintainer community is stagnating.

That doesn't mean people should step down entirely. But it does mean
they need to recognize when this is happening and, at least, proactively
try to bring new people in, instead of just continuing to play a
gatekeeping role. The role of maintainers should not be that of a wall
people have to climb over to get their changes in, it should be to guide
new contributors and help onboard people who can contribute, as peers
and eventually as future maintainers.

Kalle, in the other thread you said "this is not fun anymore, this is
more like a business with requirements and demands coming from
everywhere.". That's what it feels like to us when our changes get
rejected because the local vars aren't in reverse Christmas tree order,
or because our commit messages have "v2:" in them. It feels like some
manager is trying to justify their position by creating busywork for
everyone else. Nobody should actually care about any of those things,
and if they do, they need to step back and really ask themselves how
they ended up believing that. If the goal is to enforce a reasonable
shared coding style so things don't spiral into chaos, FFS, let's just
do what every other project does these days and adopt clang-format. Then
*all* of us can stop wasting time on these trivialities and go back to
getting stuff done. And really, nobody cares about commit messages as
long as the tags are right, the subject line is succinct, and the
important information is in there. Extra stuff never hurt anyone.

> I added the ground work for multi-vendor support, but have not decided 
> on the approach to take. Abstract per firmware interface primitive or 
> simply have a cfg80211.c and fwil_types.h per vendor OR implement a 
> vendor-specific cfg80211 callback and override the default callback 
> during the driver attach, ie. in brcmf_fwvid_wcc_attach(). The latter 
> duplicates things, but lean towards that as it may be easier on the 
> long-term. What do your tea leaves tell you ;-)

FWIW, I was hoping you'd stay on at least as a reviewer. Your
contributions are valuable. You obviously know the driver and hardware
much better than most people. I encourage you to, at least, post a v2 of
the MAINTAINERS patch with yourself as an R: line.

As far as the actual driver abstraction architecture, I'm going to leave
it to Daniel to decide what makes the most sense, since he's the one
introducing new mechanisms for that already. There's always room for
refactoring later though, depending on the direction things take with
the vendor split. BTW, clang-format also makes refactoring a lot less
painful ;)

- Hector

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

[Marcel Holtmann]

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

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

[Eric Curtin]

On Fri, 22 Dec 2023 at 05:19, Hector Martin <marcan@marcan.st> wrote:
>
>
>
> On 2023/12/21 18:57, Arend van Spriel wrote:
> > - SHA-cyfmac-dev-list@infineon.com
> >
> > On 12/21/2023 1:49 AM, Hector Martin wrote:
> >>
> >>
> >> On 2023/12/21 4:36, Arend van Spriel wrote:
> >>> On 12/20/2023 7:14 PM, Hector Martin wrote:
> >>>>
> >>>>
> >>>> On 2023/12/20 19:20, Kalle Valo wrote:
> >>>>> Linus Torvalds <torvalds@linux-foundation.org> writes:
> >>>>>
> >>>>>>> Just recently a patch was posted to remove the Infineon list from
> >>>>>>> MAINTAINERS because that company cares so little they have literally
> >>>>>>> stopped accepting emails from us. Meanwhile they are telling their
> >>>>>>> customers that they do not recommend upstream brcmfmac and they should
> >>>>>>> use their downstream driver [1].
> >>>>>>
> >>>>>> Unquestionably broadcom is not helping maintain things, and I think it
> >>>>>> should matter.
> >>>>>>
> >>>>>> As Hector says, they point to their random driver dumps on their site
> >>>>>> that you can't even download unless you are a "Broadcom community
> >>>>>> member" or whatever, and hey - any company that works that way should
> >>>>>> be seen as pretty much hostile to any actual maintenance and proper
> >>>>>> development.
> >>>>>
> >>>>> Sadly this is the normal in the wireless world. All vendors focus on the
> >>>>> latest generation, currently it's Wi-Fi 7, and lose interest on older
> >>>>> generations. And vendors lose focus on the upstream drivers even faster,
> >>>>> usually after a customer project ends.
> >>>>>
> >>>>> So in practise what we try to do is keep the drivers working somehow on
> >>>>> our own, even after the vendors are long gone. If we would deliberately
> >>>>> allow breaking drivers because vendor/corporations don't support us, I
> >>>>> suspect we would have sevaral broken drivers in upstream.
> >>>>>
> >>>>>> If Daniel and Hector are responsive to actual problem reports for the
> >>>>>> changes they cause, I do think that should count a lot.
> >>>>>
> >>>>> Sure, but they could also respect to the review comments. I find Arend's
> >>>>> proposal is reasonable and that's what I would implement in v2. We
> >>>>> (linux-wireless) make abstractions to workaround firmware problems or
> >>>>> interface conflicts all the time, just look at ath10k for example. I
> >>>>> would not be surprised if we need to add even more abstractions to
> >>>>> brcmfmac in the future. And Arend is the expert here, he has best
> >>>>> knowledge of Broadcom devices and I trust him.
> >>>>>
> >>>>> Has anyone even investigated what it would need to implement Arend's
> >>>>> proposal? At least I don't see any indication of that.
> >>>>
> >>>> Of course we can implement it (and we will as we actually got a report
> >>>> of this patch breaking Cypress now, finally).
> >>>>
> >>>> The question was never whether it could be done, we're already doing a
> >>>> bunch of abstractions to deal with just the Broadcom-only side of things
> >>>> too. The point I was trying to make is that we need to *know* what
> >>>> firmware abstractions we need and *why* they are needed. We can't just
> >>>> say, for every change, "well, nobody knows if the existing code works or
> >>>> not, so let's just add an abstraction just in case the change breaks
> >>>> something". As far as anyone involved in the discussions until now could
> >>>> tell, this code was just something some Cypress person dumped upstream,
> >>>> and nobody involved was being responsive to any of our inquiries, so
> >>>> there was no way to be certain it worked at all, whether it was
> >>>> supported in public firmware, or anything else.
> >>>>
> >>>> *Now* that we know the existing code is actually functional and not just
> >>>> dead/broken, and that the WSEC approach is conversely not functional on
> >>>> the Cypress firmwares, it makes sense to introduce an abstraction.
> >>>
> >>> Just a quick look in the git history could have told you that it was not
> >>> just dumped upstream and at least one person was using it and extended
> >>> it for 802.11r support (fast-roaming):
> >>>
> >>>
> >>> author      Paweł Drewniak <czajernia@gmail.com>    2021-08-24 23:13:30 +0100
> >>> committer   Kalle Valo <kvalo@codeaurora.org>       2021-08-29 11:33:07 +0300
> >>> commit      4b51de063d5310f1fb297388b7955926e63e45c9 (patch)
> >>> tree        ba2ccb5cbd055d482a8daa263f5e53531c07667f
> >>> /drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> >>> parent      81f9ebd43659320a88cae8ed5124c50b4d47ab66 (diff)
> >>> download    wireless-4b51de063d5310f1fb297388b7955926e63e45c9.tar.gz
> >>> brcmfmac: Add WPA3 Personal with FT to supported cipher suites
> >>> This allows the driver to connect to BSSIDs supporting SAE with 802.11r.
> >>> Tested on Raspberry Pi 4 Model B (STA) and UniFi 6LR/OpenWRT 21.02.0-rc2.
> >>> AP was set to 'sae-mixed' (WPA2/3 Personal).
> >>>
> >>> Signed-off-by: Paweł Drewniak <czajernia@gmail.com>
> >>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> >>> Link: https://lore.kernel.org/r/20210824221330.3847139-1-czajernia@gmail.com
> >>
> >> Sure, but we also had user reports of it *not* actually working (maybe
> >> it regressed?). We didn't know whether it was functional with the
> >> linux-firmware blobs in any way, I wanted confirmation of that. And we
> >> also didn't know that the patch *would* break it at all; perhaps the
> >> Cypress firmware had also grown support for the WSEC mechanism.
> >>
> >> That's why I wanted someone to actually confirm the code worked (in some
> >> subset of cases) and the patch didn't, before starting to introduce
> >> conditionals. There is, of course, also the element that the Cypress
> >> side has been long unmaintained, and if nobody is testing/giving
> >> feedback/complaining, perhaps it's better to err on the side of maybe
> >> breaking something and see if that gets someone to come out of the
> >> woodwork if it really breaks, rather than tiptoeing around the code
> >> without knowing what's going on and without anyone actually testing things.
> >
> > That is because you distrust the intent that Cypress was really
> > contributing. They were and I trusted them to not just throw in a
> > feature like WPA3. When Infineon took over they went mute. Upon
> > reviewing your patch (again) I also sent an email to them asking
> > specifically about the status of the sae_password interface. I did not
> > use the mailing list which indeed bounces these days (hence removed
> > them) but the last living soul that I had contact with about a year ago
> > whether they were still comitted to be involved. I guess out of
> > politeness or embarrassment I got confirmation they were and never heard
> > from him again. The query about the sae_password interface is still pending.
>
> If only corporate acquisition politics didn't repeatedly throw a wrench
> into this one... :/
>
> This is where we are though, Infineon clearly doesn't care, so it's time
> to move on.
>
> >> It's not about this *specific* patch, it's about the general situation
> >> of not being able to touch firmware interfaces "just in case Cypress
> >> breaks" being unsustainable in the long term. I wasn't pushing back
> >> because I think this particular one will be hard, I was pushing back
> >> because I can read the tea leaves and see this is not going to end well
> >> if it's the approach we start taking for everything. We *need* someone
> >> to be testing patches on Cypress, we can't just "try not to touch it"
> >> and cross our fingers. That just ends in disaster, we are not going to
> >> succeed in not breaking it either way and it's going to make the driver
> >> worse.
> >
> > I admire you ability of reading tea leaves. You saw the Grim I reckon.
> > Admittedly your responses on every comment from my side (or Kalle for
> > that matter) was polarizing every discussion. That is common way people
> > treat each other nowadays especially online where a conversation is just
> > a pile of text going shit. It does not bring out the best in me either,
> > but it was draining every ounce of energy from me so better end it by
> > stepping out.
>
> The hilariously outdated kernel development model surely doesn't help
> either (I've stated my opinion on this quite a few times if you've
> followed around) ;)
>
> This stuff gets *really* frustrating when you're trying to improve what
> is, I hope we can all admit, an undermaintained driver (that is not to
> say it's anyone's fault personally), and end up getting held back due to
> everything from coding style nitpicks to people not having the time to
> be responsive. It's just not helpful. It's important to know when to
> step aside and let people actually get stuff done.
>
> When Daniel started sending me brcmfmac patches downstream, I took a
> look at a few of them, decided he knew what he was doing, and just
> started pulling in his branches wholesale. Was it perfect? No, I had to
> debug at least one regression at one point. But it took me less time to
> do that than it would've to go through the commits with a fine toothed
> comb, so it was clearly the right decision.
>
> That is not to say that should be the standard upstream (we make a point
> of moving fast and breaking things more downstream, since it's a proving
> ground for what eventually will be upstreamed), but I think it does
> demonstrate the kind of delegation ability that is sorely lacking in
> many drivers and subsystems in the kernel these days. Maintainers become
> entrenched in their position, long beyond the point where they have the
> time/motivation/ability to drive the code forward, and end up in the way
> of new people who are trying to make a difference. I think Linus knows
> full well the kernel maintainer community is stagnating.
>
> That doesn't mean people should step down entirely. But it does mean
> they need to recognize when this is happening and, at least, proactively
> try to bring new people in, instead of just continuing to play a
> gatekeeping role. The role of maintainers should not be that of a wall
> people have to climb over to get their changes in, it should be to guide
> new contributors and help onboard people who can contribute, as peers
> and eventually as future maintainers.
>
> Kalle, in the other thread you said "this is not fun anymore, this is
> more like a business with requirements and demands coming from
> everywhere.". That's what it feels like to us when our changes get
> rejected because the local vars aren't in reverse Christmas tree order,
> or because our commit messages have "v2:" in them. It feels like some
> manager is trying to justify their position by creating busywork for
> everyone else. Nobody should actually care about any of those things,
> and if they do, they need to step back and really ask themselves how
> they ended up believing that. If the goal is to enforce a reasonable
> shared coding style so things don't spiral into chaos, FFS, let's just
> do what every other project does these days and adopt clang-format. Then
> *all* of us can stop wasting time on these trivialities and go back to
> getting stuff done. And really, nobody cares about commit messages as
> long as the tags are right, the subject line is succinct, and the
> important information is in there. Extra stuff never hurt anyone.
>
> > I added the ground work for multi-vendor support, but have not decided
> > on the approach to take. Abstract per firmware interface primitive or
> > simply have a cfg80211.c and fwil_types.h per vendor OR implement a
> > vendor-specific cfg80211 callback and override the default callback
> > during the driver attach, ie. in brcmf_fwvid_wcc_attach(). The latter
> > duplicates things, but lean towards that as it may be easier on the
> > long-term. What do your tea leaves tell you ;-)
>
> FWIW, I was hoping you'd stay on at least as a reviewer. Your
> contributions are valuable. You obviously know the driver and hardware
> much better than most people. I encourage you to, at least, post a v2 of
> the MAINTAINERS patch with yourself as an R: line.

I generally agree with this email, especially that Arend should stay
on as a reviewer/maintainer.

We need more people as either maintainers/contributors/reviewers/code
writers/testers, not less, to delegate, co-maintain, test, merge, make
the code more portable to many wifi devices, etc.

What really matters at the end of the day I guess is writing the code
that works across all the devices and testing it.

Which is why I spread awareness about this area, got 100s of
responses, especially on Linkedin, there's at least a portion of these
that want to help, in good spirits.

Is mise le meas/Regards,

Eric Curtin

>
> As far as the actual driver abstraction architecture, I'm going to leave
> it to Daniel to decide what makes the most sense, since he's the one
> introducing new mechanisms for that already. There's always room for
> refactoring later though, depending on the direction things take with
> the vendor split. BTW, clang-format also makes refactoring a lot less
> painful ;)
>
> - Hector
>

Testing bits/080-wifi on BCM4345/6 (was: Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password)

[Paul Fertser]

[-- Attachment #1: Type: text/plain, Size: 5940 bytes --]

Hello,

Trimming the CC list to only those involved in this downstream branch.

On Thu, Dec 21, 2023 at 03:02:00AM +0900, Hector Martin wrote:
> Are you willing to test all the other wifi stuff we have queued up
> downstream? There's a whole pile of changes here:
> 
> https://github.com/AsahiLinux/linux/commits/bits/080-wifi/

I gave this a quick test on Ampack AP6255 (BCM4345/6) which is an SDIO
module inside "Pinebook Pro". I used the branch as is, so everything
else is vanilla upstream 6.6.

Firmware (and clm_blob and txt) are from Linux firmware git tree:
[  395.218191] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2
[  395.219641] brcmfmac: brcmf_c_preinit_dcmds CLM version = API: 12.2 Data: Cypress.CYW43455 Compiler: 1.29.4 ClmImport: 1.36.3 Customization: v1 200520 Creation: 2021-04-15 02:48:59 
[  395.223732] brcmfmac: brcmf_feat_firmware_capabilities [ ap sta wme 802.11d 802.11h rm cqa cac dualband ampdu ampdu_tx ampdu_rx amsdurx radio_pwrsave btamp p2p proptxstatus mchan p2po anqpo vht-prop-rates dfrts txpwrcache stbc-tx stbc-rx-1ss epno pfnx wnm bsstrans mfp sae idauth ]


What was tested (all on 2.4 GHz band):

1. STA mode for connecting to WPA2-CCMP, no regressions compared to 6.4;

2. STA mode against WPA3 Personal, connecting and short ssh
session, works only after reverting the SAE patch;

3. AP mode Open/WPA/WPA2-TKIP/WPA2-RSN works before and after;
enabling mandatory 802.11w prevents AP from starting (a message about
mismatching parameters is emitted to dmesg), making it optional
produces no errors but the AP didn't beacon;

4. AP mode WPA3 SAE starts and beacons but connection to it is
impossible (probably due to a user error, haven't tested much).


I'm attaching a debug INFO log for driver startup for your
reference. Also attached are capabilities as reported by "iw list"
before and after.


The capabilities raise questions so I'd like to discuss some
diff hunks individually.

> +               * CCMP-256 (00-0f-ac:10)
> +               * GCMP-128 (00-0f-ac:8)
> +               * GCMP-256 (00-0f-ac:9)
> +               * CMAC-256 (00-0f-ac:13)
> +               * GMAC-128 (00-0f-ac:11)
> +               * GMAC-256 (00-0f-ac:12)

I only have easy means to test WPA3 Personal (without FT) so
00-0f-ac:8. I might be able to try WPA3 EAP later if really needed but
since I never configured it before that might be problematic. Where
"AP PeerKey" protocol is used I do not even have an idea (WPA3-secured
meshes? but capabilities indicate 802.11s isn't supported at all).

> -       Available Antennas: TX 0 RX 0
> +       Available Antennas: TX 0x1 RX 0x1

This is good.

> +               HE Iftypes: managed
> +                       HE MAC Capabilities (0x0c074a180040):
> ...

Because he_enable is an auto variable without an initial value the new
code misdetects presence of HE capabilities.

> -                       * 2412 MHz [1] (20.0 dBm)
> +                       * 2412 MHz [1] (30.0 dBm)

Not sure if this is correct for the hardware or not, the datasheet
claims maximum output power 14 dBm for 802.11n on this band.

> +                       * 2467 MHz [12] (disabled)
> +                       * 2472 MHz [13] (disabled)
> +                       * 2484 MHz [14] (disabled)

Hm, they were enabled. I'm running without a regulatory database, so
all defaults. Probably makes sense that they're not available in this
case, but will they get enabled if regulatory is set correctly?

> -               VHT Capabilities (0x00001020):
> +               VHT Capabilities (0x33801030):
>                         Max MPDU length: 3895
>                         Supported Channel Width: neither 160 nor 80+80
> +                       RX LDPC

Not sure how to test if this works.

>                         short GI (80 MHz)
>                         SU Beamformee
> +                       RX antenna pattern consistency
> +                       TX antenna pattern consistency

Makes sense for a 1x1 device.

> -               VHT RX highest supported: 0 Mbps
> +               VHT RX highest supported: 433 Mbps
...
> -               VHT TX highest supported: 0 Mbps
> +               VHT TX highest supported: 433 Mbps

Good.

> -                       * 5170 MHz [34] (20.0 dBm)
> -                       * 5180 MHz [36] (20.0 dBm)
> -                       * 5190 MHz [38] (20.0 dBm)
> -                       * 5200 MHz [40] (20.0 dBm)
> +                       * 5170 MHz [34] (disabled)
> +                       * 5180 MHz [36] (30.0 dBm)
> +                       * 5190 MHz [38] (disabled)
> +                       * 5200 MHz [40] (30.0 dBm)

VHT40, VHT80 disabled by regulatory? The datasheet claims 12 dBm for
802.11ac, not sure how that translates into dBm here.

> +       Device supports low priority scan.
> +               * [ LOW_SPAN_SCAN ]: low span scan
> +               * [ LOW_POWER_SCAN ]: low power scan
> +               * [ HIGH_ACCURACY_SCAN ]: high accuracy scan

No idea how to test.

I also spotted interesting combinations that didn't change:

>         valid interface combinations:
>                   * #{ managed } <= 2, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
>                     total <= 3, #channels <= 2

This means that I should be able to create two VIFs on same phy and
they should be able to connect to APs on different channels. That is
unusual and probably not true for this hardware, but I haven't tested.

>                   * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
>                     total <= 4, #channels <= 1

This means I should be able to run a client and an AP on the same PHY
at the same time, but only if they share the channel. This might be
useful, but I haven't tried it yet.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

[-- Attachment #2: brcmfmac-debug.txt --]
[-- Type: text/plain, Size: 19832 bytes --]

[  395.072045] brcmfmac: F1 signature read @0x18000000=0x15264345
[  395.072677] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345/6
[  395.074614] brcmfmac: brcmf_chip_cores_check  [1 ] core 0x800:51  base 0x18000000 wrap 0x18100000
[  395.075298] brcmfmac: brcmf_chip_cores_check  [2 ] core 0x812:54  base 0x18001000 wrap 0x18101000
[  395.075970] brcmfmac: brcmf_chip_cores_check  [3 ] core 0x83e:9   base 0x18002000 wrap 0x18102000
[  395.076655] brcmfmac: brcmf_chip_cores_check  [4 ] core 0x83c:14  base 0x18003000 wrap 0x18103000
[  395.077339] brcmfmac: brcmf_chip_cores_check  [5 ] core 0x829:21  base 0x18004000 wrap 0x18104000
[  395.078010] brcmfmac: brcmf_chip_cores_check  [6 ] core 0x135:0   base 0x00000000 wrap 0x18107000
[  395.078694] brcmfmac: brcmf_chip_cores_check  [7 ] core 0x240:0   base 0x00000000 wrap 0x00000000
[  395.080362] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x198000 size=819200 (0xc8000) sr=0 (0x0)
[  395.081085] brcmfmac: brcmf_chip_setup ccrev=51, pmurev=27, pmucaps=0x39d05f1b
[  395.081641] brcmfmac: brcmf_get_module_param Enter, bus=0, chip=17221, rev=6
[  395.082212] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver strength init needed for chip BCM4345/6 rev 6 pmurev 27
[  395.083640] brcmfmac: brcmf_sdio_probe completed!!
[  395.083992] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[  395.097438] OF: graph: no port node found in /i2c@ff3d0000/fusb30x@22
[  395.104500] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x00198000; size=643651
[  395.131027] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x0025f950; size=1712
[  395.207823] brcmfmac: brcmf_sdio_firmware_callback enable F2: err=0
[  395.208335] brcmfmac: brcmf_sdio_firmware_callback set F2 watermark to 0x60*4 bytes
[  395.208991] brcmfmac: brcmf_sdio_sr_init SR enabled
[  395.209324] brcmfmac: brcmf_bus_change_state ignoring transition, bus not attached yet
[  395.210006] brcmfmac: brcmf_wcc_attach: executing
[  395.210339] brcmfmac: brcmf_add_if allocate netdev interface
[  395.211193] brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x00208AC0
[  395.212451] brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x00208AC0
[  395.217200] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[  395.218191] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2
[  395.219641] brcmfmac: brcmf_c_preinit_dcmds CLM version = API: 12.2 Data: Cypress.CYW43455 Compiler: 1.29.4 ClmImport: 1.36.3 Customization: v1 200520 Creation: 2021-04-15 02:48:59 
[  395.223732] brcmfmac: brcmf_feat_firmware_capabilities [ ap sta wme 802.11d 802.11h rm cqa cac dualband ampdu ampdu_tx ampdu_rx amsdurx radio_pwrsave btamp p2p proptxstatus mchan p2po anqpo vht-prop-rates dfrts txpwrcache stbc-tx stbc-rx-1ss epno pfnx wnm bsstrans mfp sae idauth ]
[  395.225893] brcmfmac: brcmf_feat_firmware_capabilities enabling feature: MCHAN
[  395.226445] brcmfmac: brcmf_feat_firmware_capabilities enabling feature: P2P
[  395.227031] brcmfmac: brcmf_feat_firmware_capabilities enabling feature: DOT11H
[  395.227592] brcmfmac: brcmf_feat_firmware_capabilities enabling feature: SAE
[  395.228111] brcmfmac: brcmf_feat_firmware_capabilities enabling feature: FWAUTH
[  395.229482] brcmfmac: brcmf_feat_iovar_int_get enabling feature: PNO
[  395.231822] brcmfmac: brcmf_feat_iovar_int_get enabling feature: MFP
[  395.232783] brcmfmac: brcmf_feat_iovar_int_get enabling feature: DUMP_OBSS
[  395.233827] brcmfmac: brcmf_feat_iovar_int_get enabling feature: EVENT_MSGS_EXT
[  395.235570] brcmfmac: brcmf_feat_iovar_int_get enabling feature: FWSUP
[  395.240819] brcmfmac: brcmf_fws_attach FWS queueing will be avoided
[  395.241859] brcmfmac: brcmf_cfg80211_attach Registering custom regulatory
[  395.246547] brcmfmac: brcmf_setup_wiphybands nmode=1, vhtmode=1, bw_cap=(1, 7, 0), he_enable=255
[  395.247565] brcmfmac: brcmf_setup_wiphybands nrxchain=1
[  395.249084] brcmfmac: brcmf_setup_wiphybands ntxchain=1
[  395.264847] brcmfmac: brcmf_enable_bw40_2g Check bw_cap support:0
[  395.266100] brcmfmac: brcmf_enable_bw40_2g set bw_cap support:0
[  395.287615] brcmfmac: brcmf_add_if netdev:wlan%d ignore IF event
[  395.296599] brcmfmac: check_vif_up device is not ready : status (0)
[  395.297460] brcmfmac: brcmf_net_attach wlan0: Broadcom Dongle Host Driver
[  395.465283] brcmfmac: check_vif_up device is not ready : status (0)
[  395.519938] brcmfmac: check_vif_up device is not ready : status (0)
[  395.520985] brcmfmac: check_vif_up device is not ready : status (0)
[  395.522835] brcmfmac: check_vif_up device is not ready : status (0)
[  395.523975] brcmfmac: check_vif_up device is not ready : status (0)
[  395.526957] brcmfmac: check_vif_up device is not ready : status (0)
[  395.528813] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  395.530098] brcmfmac: brcmf_config_dongle power save set to enabled
[  395.531130] brcmfmac: brcmf_dongle_roam Internal Roaming = On
[  395.532668] ieee80211 phy1: brcmf_dongle_roam: WLC_SET_ROAM_DELTA error (-52)
[  395.533460] brcmfmac: brcmf_cfg80211_change_iface IF Type = Infra
[  395.535500] brcmfmac: brcmf_cfg80211_set_power_mgmt power save enabled
[  395.570081] brcmfmac: brcmf_p2p_add_vif adding vif "p2p-dev-wlan0" (type=10)
[  395.595209] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  395.598514] brcmfmac: brcmf_add_if allocate non-netdev interface
[  395.599744] brcmfmac: check_vif_up device is not ready : status (0)
[  395.600225] brcmfmac: check_vif_up device is not ready : status (0)
[  395.627472] brcmfmac: check_vif_up device is not ready : status (0)
[  395.628569] brcmfmac: check_vif_up device is not ready : status (0)
[  395.629105] brcmfmac: check_vif_up device is not ready : status (0)
[  395.629691] brcmfmac: check_vif_up device is not ready : status (0)
[  395.631412] brcmfmac: check_vif_up device is not ready : status (0)
[  395.632404] brcmfmac: check_vif_up device is not ready : status (0)
[  396.651790] brcmfmac: brcmf_set_mpc MPC : 0
[  396.652858] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  396.756760] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 1: survey duration 80
[  396.757455] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(31) rx(25) tx(0)
[  396.759360] brcmfmac: brcmf_set_mpc MPC : 1
[  396.763106] brcmfmac: brcmf_set_mpc MPC : 0
[  396.764322] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  396.866778] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 2: survey duration 80
[  396.867473] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(14) rx(7) tx(0)
[  396.868935] brcmfmac: brcmf_set_mpc MPC : 1
[  396.872837] brcmfmac: brcmf_set_mpc MPC : 0
[  396.873905] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  396.971803] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 3: survey duration 80
[  396.972495] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(11) rx(5) tx(0)
[  396.973963] brcmfmac: brcmf_set_mpc MPC : 1
[  396.977621] brcmfmac: brcmf_set_mpc MPC : 0
[  396.978619] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.084264] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 4: survey duration 80
[  397.084954] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(4) rx(3) tx(0)
[  397.086392] brcmfmac: brcmf_set_mpc MPC : 1
[  397.089731] brcmfmac: brcmf_set_mpc MPC : 0
[  397.090957] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.194820] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 5: survey duration 80
[  397.195513] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(8) rx(7) tx(0)
[  397.196873] brcmfmac: brcmf_set_mpc MPC : 1
[  397.200779] brcmfmac: brcmf_set_mpc MPC : 0
[  397.201915] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.298786] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 6: survey duration 80
[  397.299477] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(5) rx(5) tx(0)
[  397.300932] brcmfmac: brcmf_set_mpc MPC : 1
[  397.304839] brcmfmac: brcmf_set_mpc MPC : 0
[  397.307116] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.410824] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 7: survey duration 80
[  397.411515] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(4) rx(2) tx(0)
[  397.412972] brcmfmac: brcmf_set_mpc MPC : 1
[  397.416835] brcmfmac: brcmf_set_mpc MPC : 0
[  397.418507] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.522821] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 8: survey duration 80
[  397.523513] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(5) rx(2) tx(0)
[  397.524976] brcmfmac: brcmf_set_mpc MPC : 1
[  397.528947] brcmfmac: brcmf_set_mpc MPC : 0
[  397.529924] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.626823] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 9: survey duration 80
[  397.627515] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(30) rx(15) tx(0)
[  397.629001] brcmfmac: brcmf_set_mpc MPC : 1
[  397.632953] brcmfmac: brcmf_set_mpc MPC : 0
[  397.634118] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.738904] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 10: survey duration 80
[  397.739596] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(34) rx(15) tx(0)
[  397.741058] brcmfmac: brcmf_set_mpc MPC : 1
[  397.744973] brcmfmac: brcmf_set_mpc MPC : 0
[  397.746708] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.850825] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 11: survey duration 80
[  397.851530] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(45) rx(21) tx(0)
[  397.853005] brcmfmac: brcmf_set_mpc MPC : 1
[  397.859657] brcmfmac: brcmf_set_mpc MPC : 0
[  397.860681] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  397.963804] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 36: survey duration 80
[  397.964509] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  397.966429] brcmfmac: brcmf_set_mpc MPC : 1
[  397.970558] brcmfmac: brcmf_set_mpc MPC : 0
[  397.971318] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  398.074793] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 40: survey duration 80
[  398.075494] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  398.076958] brcmfmac: brcmf_set_mpc MPC : 1
[  398.080832] brcmfmac: brcmf_set_mpc MPC : 0
[  398.082119] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  398.179086] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 44: survey duration 80
[  398.179782] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  398.182126] brcmfmac: brcmf_set_mpc MPC : 1
[  398.186636] brcmfmac: brcmf_set_mpc MPC : 0
[  398.187770] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  398.292123] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 48: survey duration 80
[  398.292825] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  398.294392] brcmfmac: brcmf_set_mpc MPC : 1
[  398.298060] brcmfmac: brcmf_set_mpc MPC : 0
[  398.299283] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  398.402846] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 149: survey duration 80
[  398.403554] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  398.405477] brcmfmac: brcmf_set_mpc MPC : 1
[  398.409291] brcmfmac: brcmf_set_mpc MPC : 0
[  398.410433] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  398.514839] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 153: survey duration 80
[  398.515548] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  398.516914] brcmfmac: brcmf_set_mpc MPC : 1
[  398.520387] brcmfmac: brcmf_set_mpc MPC : 0
[  398.521771] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  398.628134] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 157: survey duration 80
[  398.628821] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  398.631069] brcmfmac: brcmf_set_mpc MPC : 1
[  398.634761] brcmfmac: brcmf_set_mpc MPC : 0
[  398.635905] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  398.739024] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 161: survey duration 80
[  398.739727] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(4) rx(4) tx(0)
[  398.741168] brcmfmac: brcmf_set_mpc MPC : 1
[  398.745229] brcmfmac: brcmf_set_mpc MPC : 0
[  398.746753] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  398.851882] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 165: survey duration 80
[  398.852588] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  398.854639] brcmfmac: brcmf_set_mpc MPC : 1
[  398.860345] brcmfmac: brcmf_cfg80211_connect ie (00000000536a005e), ie_len (50)
[  398.863858] brcmfmac: brcmf_cfg80211_connect using PSK offload
[  400.197319] brcmfmac: brcmf_set_mpc MPC : 0
[  400.198461] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  400.298901] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 1: survey duration 80
[  400.299630] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(7) rx(6) tx(0)
[  400.300985] brcmfmac: brcmf_set_mpc MPC : 1
[  400.304425] brcmfmac: brcmf_set_mpc MPC : 0
[  400.305543] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  400.411746] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 2: survey duration 80
[  400.412482] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(18) rx(2) tx(0)
[  400.414606] brcmfmac: brcmf_set_mpc MPC : 1
[  400.418427] brcmfmac: brcmf_set_mpc MPC : 0
[  400.419640] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  400.522997] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 3: survey duration 80
[  400.523724] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(6) rx(1) tx(0)
[  400.525009] brcmfmac: brcmf_set_mpc MPC : 1
[  400.528599] brcmfmac: brcmf_set_mpc MPC : 0
[  400.529467] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  400.634380] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 4: survey duration 80
[  400.635067] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(10) rx(5) tx(0)
[  400.636497] brcmfmac: brcmf_set_mpc MPC : 1
[  400.640096] brcmfmac: brcmf_set_mpc MPC : 0
[  400.641317] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  400.739354] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 5: survey duration 80
[  400.740042] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(14) rx(8) tx(0)
[  400.741489] brcmfmac: brcmf_set_mpc MPC : 1
[  400.746357] brcmfmac: brcmf_set_mpc MPC : 0
[  400.748176] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  400.851630] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 6: survey duration 80
[  400.852370] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(7) rx(4) tx(0)
[  400.853441] brcmfmac: brcmf_set_mpc MPC : 1
[  400.856617] brcmfmac: brcmf_set_mpc MPC : 0
[  400.857521] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  400.963840] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 7: survey duration 80
[  400.964537] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(16) rx(3) tx(0)
[  400.966451] brcmfmac: brcmf_set_mpc MPC : 1
[  400.970051] brcmfmac: brcmf_set_mpc MPC : 0
[  400.971301] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.074866] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 8: survey duration 80
[  401.075562] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(11) rx(4) tx(0)
[  401.077027] brcmfmac: brcmf_set_mpc MPC : 1
[  401.080886] brcmfmac: brcmf_set_mpc MPC : 0
[  401.083207] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.187275] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 9: survey duration 80
[  401.187920] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(26) rx(14) tx(0)
[  401.190161] brcmfmac: brcmf_set_mpc MPC : 1
[  401.194421] brcmfmac: brcmf_set_mpc MPC : 0
[  401.195866] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.299885] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 10: survey duration 80
[  401.300587] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(35) rx(15) tx(0)
[  401.302060] brcmfmac: brcmf_set_mpc MPC : 1
[  401.306285] brcmfmac: brcmf_set_mpc MPC : 0
[  401.308198] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.410857] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 11: survey duration 80
[  401.411557] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(45) rx(23) tx(0)
[  401.413040] brcmfmac: brcmf_set_mpc MPC : 1
[  401.419702] brcmfmac: brcmf_set_mpc MPC : 0
[  401.420735] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.523854] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 36: survey duration 80
[  401.524557] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  401.526083] brcmfmac: brcmf_set_mpc MPC : 1
[  401.530830] brcmfmac: brcmf_set_mpc MPC : 0
[  401.532774] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.635001] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 40: survey duration 80
[  401.635692] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  401.637607] brcmfmac: brcmf_set_mpc MPC : 1
[  401.641687] brcmfmac: brcmf_set_mpc MPC : 0
[  401.642380] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.746908] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 44: survey duration 80
[  401.747608] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  401.748978] brcmfmac: brcmf_set_mpc MPC : 1
[  401.752979] brcmfmac: brcmf_set_mpc MPC : 0
[  401.753965] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.850877] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 48: survey duration 80
[  401.851580] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  401.853056] brcmfmac: brcmf_set_mpc MPC : 1
[  401.856971] brcmfmac: brcmf_set_mpc MPC : 0
[  401.857750] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  401.962855] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 149: survey duration 80
[  401.963563] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  401.964933] brcmfmac: brcmf_set_mpc MPC : 1
[  401.969210] brcmfmac: brcmf_set_mpc MPC : 0
[  401.970004] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  402.066718] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 153: survey duration 80
[  402.067424] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  402.069220] brcmfmac: brcmf_set_mpc MPC : 1
[  402.073109] brcmfmac: brcmf_set_mpc MPC : 0
[  402.074007] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  402.179863] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 157: survey duration 80
[  402.180575] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  402.182099] brcmfmac: brcmf_set_mpc MPC : 1
[  402.186595] brcmfmac: brcmf_set_mpc MPC : 0
[  402.188587] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  402.290891] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 161: survey duration 80
[  402.291601] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(4) rx(3) tx(0)
[  402.293528] brcmfmac: brcmf_set_mpc MPC : 1
[  402.297351] brcmfmac: brcmf_set_mpc MPC : 0
[  402.299501] brcmfmac: brcmf_add_if netdev:wlan0 ignore IF event
[  402.402844] brcmfmac: brcmf_cfg80211_dump_survey OBSS dump: channel 165: survey duration 80
[  402.403548] brcmfmac: brcmf_cfg80211_dump_survey noise(0) busy(80) rx(0) tx(0)
[  402.404979] brcmfmac: brcmf_set_mpc MPC : 1
[  402.410096] brcmfmac: brcmf_cfg80211_connect ie (0000000022a18edb), ie_len (50)
[  402.415897] brcmfmac: brcmf_cfg80211_connect using PSK offload

[-- Attachment #3: brcmfmac-iw-list-upstream.txt --]
[-- Type: text/plain, Size: 5531 bytes --]

Wiphy phy0
	wiphy index: 0
	max # scan SSIDs: 10
	max scan IEs length: 2048 bytes
	max # sched scan SSIDs: 16
	max # match sets: 16
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports roaming.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* CMAC (00-0f-ac:6)
	Available Antennas: TX 0 RX 0
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * P2P-client
		 * P2P-GO
		 * P2P-device
	Band 1:
		Capabilities: 0x1022
			HT20/HT40
			Static SM Power Save
			RX HT20 SGI
			No RX STBC
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 16 usec (0x07)
		HT TX/RX MCS rate indexes supported: 0-7
		Bitrates (non-HT):
			* 1.0 Mbps
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412 MHz [1] (20.0 dBm)
			* 2417 MHz [2] (20.0 dBm)
			* 2422 MHz [3] (20.0 dBm)
			* 2427 MHz [4] (20.0 dBm)
			* 2432 MHz [5] (20.0 dBm)
			* 2437 MHz [6] (20.0 dBm)
			* 2442 MHz [7] (20.0 dBm)
			* 2447 MHz [8] (20.0 dBm)
			* 2452 MHz [9] (20.0 dBm)
			* 2457 MHz [10] (20.0 dBm)
			* 2462 MHz [11] (20.0 dBm)
			* 2467 MHz [12] (20.0 dBm)
			* 2472 MHz [13] (20.0 dBm)
			* 2484 MHz [14] (20.0 dBm)
	Band 2:
		Capabilities: 0x1062
			HT20/HT40
			Static SM Power Save
			RX HT20 SGI
			RX HT40 SGI
			No RX STBC
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 16 usec (0x07)
		HT TX/RX MCS rate indexes supported: 0-7
		VHT Capabilities (0x00001020):
			Max MPDU length: 3895
			Supported Channel Width: neither 160 nor 80+80
			short GI (80 MHz)
			SU Beamformee
		VHT RX MCS set:
			1 streams: MCS 0-9
			2 streams: not supported
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 0 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-9
			2 streams: not supported
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 0 Mbps
		VHT extended NSS: not supported
		Bitrates (non-HT):
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 5170 MHz [34] (20.0 dBm)
			* 5180 MHz [36] (20.0 dBm)
			* 5190 MHz [38] (20.0 dBm)
			* 5200 MHz [40] (20.0 dBm)
			* 5210 MHz [42] (20.0 dBm)
			* 5220 MHz [44] (20.0 dBm)
			* 5230 MHz [46] (20.0 dBm)
			* 5240 MHz [48] (20.0 dBm)
			* 5260 MHz [52] (20.0 dBm)
			* 5280 MHz [56] (20.0 dBm)
			* 5300 MHz [60] (20.0 dBm)
			* 5320 MHz [64] (20.0 dBm)
			* 5500 MHz [100] (20.0 dBm)
			* 5520 MHz [104] (20.0 dBm)
			* 5540 MHz [108] (20.0 dBm)
			* 5560 MHz [112] (20.0 dBm)
			* 5580 MHz [116] (20.0 dBm)
			* 5600 MHz [120] (20.0 dBm)
			* 5620 MHz [124] (20.0 dBm)
			* 5640 MHz [128] (20.0 dBm)
			* 5660 MHz [132] (20.0 dBm)
			* 5680 MHz [136] (20.0 dBm)
			* 5700 MHz [140] (20.0 dBm)
			* 5720 MHz [144] (20.0 dBm)
			* 5745 MHz [149] (20.0 dBm)
			* 5765 MHz [153] (20.0 dBm)
			* 5785 MHz [157] (20.0 dBm)
			* 5805 MHz [161] (20.0 dBm)
			* 5825 MHz [165] (20.0 dBm)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * join_ibss
		 * set_pmksa
		 * del_pmksa
		 * flush_pmksa
		 * remain_on_channel
		 * frame
		 * set_wiphy_netns
		 * set_channel
		 * start_sched_scan
		 * start_p2p_device
		 * connect
		 * disconnect
		 * crit_protocol_start
		 * crit_protocol_stop
		 * update_connect_params
	software interface modes (can always be added):
	valid interface combinations:
		 * #{ managed } <= 2, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
		   total <= 3, #channels <= 2
		 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
		   total <= 4, #channels <= 1
	Device supports scan flush.
	Device supports randomizing MAC-addr in sched scans.
	max # scan plans: 1
	max scan plan interval: 508
	max scan plan iterations: 0
	Supported TX frame types:
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * managed: 0x40 0xd0
		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	Supported extended features:
		* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
		* [ 4WAY_HANDSHAKE_STA_PSK ]: 4-way handshake with PSK in station mode
		* [ 4WAY_HANDSHAKE_STA_1X ]: 4-way handshake with 802.1X in station mode
		* [ DFS_OFFLOAD ]: DFS offload
		* [ SAE_OFFLOAD ]: SAE offload support
		* [ 4WAY_HANDSHAKE_AP_PSK ]: AP mode PSK offload support
		* [ SAE_OFFLOAD_AP ]: AP mode SAE authentication offload support

[-- Attachment #4: brcmfmac-iw-list-dberlin.txt --]
[-- Type: text/plain, Size: 11625 bytes --]

Wiphy phy1
	wiphy index: 1
	max # scan SSIDs: 10
	max scan IEs length: 2048 bytes
	max # sched scan SSIDs: 16
	max # match sets: 16
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports roaming.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* CCMP-256 (00-0f-ac:10)
		* GCMP-128 (00-0f-ac:8)
		* GCMP-256 (00-0f-ac:9)
		* CMAC (00-0f-ac:6)
		* CMAC-256 (00-0f-ac:13)
		* GMAC-128 (00-0f-ac:11)
		* GMAC-256 (00-0f-ac:12)
	Available Antennas: TX 0x1 RX 0x1
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * P2P-client
		 * P2P-GO
		 * P2P-device
	Band 1:
		Capabilities: 0x1022
			HT20/HT40
			Static SM Power Save
			RX HT20 SGI
			No RX STBC
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 16 usec (0x07)
		HT TX/RX MCS rate indexes supported: 0-7
		HE Iftypes: managed
			HE MAC Capabilities (0x0c074a180040):
				+HTC HE Supported
				TWT Requester
				TWT Responder
				Trigger Frame MAC Padding Duration: 3
				BSR
				Broadcast TWT
				OM Control
				Maximum A-MPDU Length Exponent: 1
				Flexible TWT Scheduling
				A-MSDU in A-MPDU
			HE PHY Capabilities: (0x0e20c29e7dc1bf0c0f3c00):
				HE40/2.4GHz
				HE40/HE80/5GHz
				HE160/5GHz
				LDPC Coding in Payload
				NDP with 4x HE-LTF and 3.2us GI
				Full Bandwidth UL MU-MIMO
				Partial Bandwidth UL MU-MIMO
				DCM Max Constellation: 2
				DCM Max NSS Tx: 1
				DCM Max Constellation Rx: 3
				SU Beamformer
				SU Beamformee
				Beamformee STS <= 80Mhz: 7
				Beamformee STS > 80Mhz: 3
				Sounding Dimensions <= 80Mhz: 1
				Ng = 16 SU Feedback
				Ng = 16 MU Feedback
				Codebook Size SU Feedback
				Codebook Size MU Feedback
				Triggered SU Beamforming Feedback
				Triggered MU Beamforming Feedback
				Triggered CQI Feedback
				Partial Bandwidth Extended Range
				PPE Threshold Present
				HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
				Max NC: 1
				HE ER SU PPDU 4x HE-LTF 0.8us GI
				20MHz in 40MHz HE PPDU 2.4GHz
				20MHz in 160/80+80MHz HE PPDU
				80MHz in 160/80+80MHz HE PPDU
				TX 1024-QAM
				RX 1024-QAM
				RX Full BW SU Using HE MU PPDU with Compression SIGB
				RX Full BW SU Using HE MU PPDU with Non-Compression SIGB
			HE RX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE TX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE RX MCS and NSS set 160 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE TX MCS and NSS set 160 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			PPE Threshold 
		EHT Iftypes: managed
			EHT MAC Capabilities (0x0000):
			EHT PHY Capabilities: (0x0000000000000000):
			EHT MCS/NSS: (0x):
			EHT bw <= 80 MHz, max NSS for MCS 8-9: Rx=0, Tx=0
			EHT bw <= 80 MHz, max NSS for MCS 10-11: Rx=0, Tx=0
			EHT bw <= 80 MHz, max NSS for MCS 12-13: Rx=0, Tx=0
			EHT bw=160 MHz, max NSS for MCS 8-9: Rx=0, Tx=0
			EHT bw=160 MHz, max NSS for MCS 10-11: Rx=0, Tx=0
			EHT bw=160 MHz, max NSS for MCS 12-13: Rx=0, Tx=0
		Bitrates (non-HT):
			* 1.0 Mbps
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412 MHz [1] (30.0 dBm)
			* 2417 MHz [2] (30.0 dBm)
			* 2422 MHz [3] (30.0 dBm)
			* 2427 MHz [4] (30.0 dBm)
			* 2432 MHz [5] (30.0 dBm)
			* 2437 MHz [6] (30.0 dBm)
			* 2442 MHz [7] (30.0 dBm)
			* 2447 MHz [8] (30.0 dBm)
			* 2452 MHz [9] (30.0 dBm)
			* 2457 MHz [10] (30.0 dBm)
			* 2462 MHz [11] (30.0 dBm)
			* 2467 MHz [12] (disabled)
			* 2472 MHz [13] (disabled)
			* 2484 MHz [14] (disabled)
	Band 2:
		Capabilities: 0x1062
			HT20/HT40
			Static SM Power Save
			RX HT20 SGI
			RX HT40 SGI
			No RX STBC
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 16 usec (0x07)
		HT TX/RX MCS rate indexes supported: 0-7
		VHT Capabilities (0x33801030):
			Max MPDU length: 3895
			Supported Channel Width: neither 160 nor 80+80
			RX LDPC
			short GI (80 MHz)
			SU Beamformee
			RX antenna pattern consistency
			TX antenna pattern consistency
		VHT RX MCS set:
			1 streams: MCS 0-9
			2 streams: not supported
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 433 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-9
			2 streams: not supported
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 433 Mbps
		VHT extended NSS: not supported
		HE Iftypes: managed
			HE MAC Capabilities (0x0c074a180040):
				+HTC HE Supported
				TWT Requester
				TWT Responder
				Trigger Frame MAC Padding Duration: 3
				BSR
				Broadcast TWT
				OM Control
				Maximum A-MPDU Length Exponent: 1
				Flexible TWT Scheduling
				A-MSDU in A-MPDU
			HE PHY Capabilities: (0x0e20c29e7dc1bf0c0f3c00):
				HE40/2.4GHz
				HE40/HE80/5GHz
				HE160/5GHz
				LDPC Coding in Payload
				NDP with 4x HE-LTF and 3.2us GI
				Full Bandwidth UL MU-MIMO
				Partial Bandwidth UL MU-MIMO
				DCM Max Constellation: 2
				DCM Max NSS Tx: 1
				DCM Max Constellation Rx: 3
				SU Beamformer
				SU Beamformee
				Beamformee STS <= 80Mhz: 7
				Beamformee STS > 80Mhz: 3
				Sounding Dimensions <= 80Mhz: 1
				Ng = 16 SU Feedback
				Ng = 16 MU Feedback
				Codebook Size SU Feedback
				Codebook Size MU Feedback
				Triggered SU Beamforming Feedback
				Triggered MU Beamforming Feedback
				Triggered CQI Feedback
				Partial Bandwidth Extended Range
				PPE Threshold Present
				HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
				Max NC: 1
				HE ER SU PPDU 4x HE-LTF 0.8us GI
				20MHz in 40MHz HE PPDU 2.4GHz
				20MHz in 160/80+80MHz HE PPDU
				80MHz in 160/80+80MHz HE PPDU
				TX 1024-QAM
				RX 1024-QAM
				RX Full BW SU Using HE MU PPDU with Compression SIGB
				RX Full BW SU Using HE MU PPDU with Non-Compression SIGB
			HE RX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE TX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE RX MCS and NSS set 160 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE TX MCS and NSS set 160 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			PPE Threshold 
		EHT Iftypes: managed
			EHT MAC Capabilities (0x0000):
			EHT PHY Capabilities: (0x0000000000000000):
			EHT MCS/NSS: (0x):
			EHT bw <= 80 MHz, max NSS for MCS 8-9: Rx=0, Tx=0
			EHT bw <= 80 MHz, max NSS for MCS 10-11: Rx=0, Tx=0
			EHT bw <= 80 MHz, max NSS for MCS 12-13: Rx=0, Tx=0
			EHT bw=160 MHz, max NSS for MCS 8-9: Rx=0, Tx=0
			EHT bw=160 MHz, max NSS for MCS 10-11: Rx=0, Tx=0
			EHT bw=160 MHz, max NSS for MCS 12-13: Rx=0, Tx=0
		Bitrates (non-HT):
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 5170 MHz [34] (disabled)
			* 5180 MHz [36] (30.0 dBm)
			* 5190 MHz [38] (disabled)
			* 5200 MHz [40] (30.0 dBm)
			* 5210 MHz [42] (disabled)
			* 5220 MHz [44] (30.0 dBm)
			* 5230 MHz [46] (disabled)
			* 5240 MHz [48] (30.0 dBm)
			* 5260 MHz [52] (disabled)
			* 5280 MHz [56] (disabled)
			* 5300 MHz [60] (disabled)
			* 5320 MHz [64] (disabled)
			* 5500 MHz [100] (disabled)
			* 5520 MHz [104] (disabled)
			* 5540 MHz [108] (disabled)
			* 5560 MHz [112] (disabled)
			* 5580 MHz [116] (disabled)
			* 5600 MHz [120] (disabled)
			* 5620 MHz [124] (disabled)
			* 5640 MHz [128] (disabled)
			* 5660 MHz [132] (disabled)
			* 5680 MHz [136] (disabled)
			* 5700 MHz [140] (disabled)
			* 5720 MHz [144] (disabled)
			* 5745 MHz [149] (30.0 dBm)
			* 5765 MHz [153] (30.0 dBm)
			* 5785 MHz [157] (30.0 dBm)
			* 5805 MHz [161] (30.0 dBm)
			* 5825 MHz [165] (30.0 dBm)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * join_ibss
		 * set_pmksa
		 * del_pmksa
		 * flush_pmksa
		 * remain_on_channel
		 * frame
		 * set_wiphy_netns
		 * set_channel
		 * start_sched_scan
		 * start_p2p_device
		 * connect
		 * disconnect
		 * crit_protocol_start
		 * crit_protocol_stop
		 * update_connect_params
	software interface modes (can always be added):
	valid interface combinations:
		 * #{ managed } <= 2, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
		   total <= 3, #channels <= 2
		 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
		   total <= 4, #channels <= 1
	Device supports low priority scan.
	Device supports scan flush.
	Device supports randomizing MAC-addr in sched scans.
	max # scan plans: 1
	max scan plan interval: 508
	max scan plan iterations: 0
	Supported TX frame types:
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * managed: 0x40 0xd0
		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	Supported extended features:
		* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
		* [ 4WAY_HANDSHAKE_STA_PSK ]: 4-way handshake with PSK in station mode
		* [ 4WAY_HANDSHAKE_STA_1X ]: 4-way handshake with 802.1X in station mode
		* [ LOW_SPAN_SCAN ]: low span scan
		* [ LOW_POWER_SCAN ]: low power scan
		* [ HIGH_ACCURACY_SCAN ]: high accuracy scan
		* [ DFS_OFFLOAD ]: DFS offload
		* [ SAE_OFFLOAD ]: SAE offload support
		* [ 4WAY_HANDSHAKE_AP_PSK ]: AP mode PSK offload support
		* [ SAE_OFFLOAD_AP ]: AP mode SAE authentication offload support

Re: Testing bits/080-wifi on BCM4345/6 (was: Re: [PATCH] wifi: brcmfmac: cfg80211: Use WSEC to set SAE password)

[Paul Fertser]

Hey Daniel,

Thank you for a rather elaborate reply, wishing you a joyful and
refreshing vacation.

On Sat, Dec 23, 2023 at 09:07:17AM -0600, Daniel Berlin wrote:
> The freq differences below are regulatory - the default of the driver before
> fixing would get stuck in it's default custom regulatory domain, which is 20dbm
> for everything.

I don't complain, just noticed it changed. What bothers me more is
every other channel in 5 GHz disabled by default which would make only
VHT20 work there.

> They should get re enabled if you move to a real domain.

I will try it later.

> I am happy to fix the sae issue when I get back if you are willing to recompile
> with the tracing flags on and get me some logs.

Sure.

> If it becomes complex I'll buy apinebook pro to test with.

I do not recommend that at all, it would be much much easier to use a
popular (so that it's supported by upstream kernel) SBC with same SDIO
module and just boot the kernel + minimal initramfs userspace via TFTP
over wired Ethernet.

> AP mode I'll see if I can fix it - it's not really tested well.  I can probably
> make local progress on this first.

Again, I'm not complaining, just tested what I could quickly test. I'm
surprised Asahi users seem to have not yet explored the topic of
allowed interface combinations, it would be curious to learn how it
works on those "more advanced" broadcom modules you got.

> P2P will also likely break if you haven't tried it.

Not even once in my life :)

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

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

[Arend van Spriel]

[-- Attachment #1: Type: text/plain, Size: 4197 bytes --]

On 12/22/2023 1:03 AM, Neal Gompa wrote:
> On Thu, Dec 21, 2023 at 3:40 PM Marcel Holtmann <marcel@holtmann.org> wrote:
>>
>> 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@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

The brcmfmac firmware has its own 802.11 stack implementation and as 
such it has a SME running in firmware which means the driver only 
implements the NL80211_CMD_CONNECT primitive. Now if the firmware also 
has in-driver supplicant (*-idsup-*) supporting SAE (*-sae-*) it can be 
offloaded. That is what Cypress went with at least for upstream. For 
firmware without these in the firmware target string the driver needs to 
implement support for NL80211_CMD_EXTERNAL_AUTH, which is what we opted 
for in Broadcom BCA (or WCC-Access as we call it these days). So I don't 
think it is a fair assessment to call the wpa_supplicant implementation 
vendor specific.

Regards,
Arend

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: Testing bits/080-wifi on BCM4345/6

[Paul Fertser]

Hi Daniel,

On Sat, Dec 23, 2023 at 09:43:55AM -0600, Daniel Berlin wrote:
> What you are seeing now is the real state.  The chip and the stack
> now have the same domain .  As such, those channels were always
> disabled *as far as the chip was concerned*, you just didn't see it
> because it didn't display it.  There is code in the driver  to
> enable vht40/80 when the regulatory domain is set right.

The global regdomain in "iw reg get" changes to the requested one but
phy#0 is left at "country 99: DFS-UNSET". However that global domain
clearly affects the channel lists as reported by "iw list".

1. 2.4 GHz channels get unlocked as they should (JP channel 14 stays
disabled but that's likely irrelevant as it's 802.11b-only)

2. 5 GHz DFS channels get all disabled, no new channels are enabled so
VHT40/80 are still not possible

That's with clm_blob from Linux firmware tree.


Another thing is the per-channel power limits reported. My current
understanding is that "iw list" should be showing the currently active
limit, that is, the minimum of: generic firmware limit, current
regulatory limit, the specific hardware limit. So 30 dBm there looks
wrong and inconsistent with the behavior of other drivers, e.g. mt76.


Regarding testing on this hardware, raspberrypi docs say that Pi4 can
be booted fully over wired network after minimal one-time
configuration so that seems to be the easiest option for development.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

Re: Testing bits/080-wifi on BCM4345/6

[Daniel Berlin]

Staring closer, it looks like there is an undocumented iovar to
retrieve some variant of per-channel txpower that is bounded by the
hardware limit, but
1. it's optional in the firmware, and only compiled into some firmware versions.

2. All broadcom drivers (IE android, bcmdhd, brcmfmac) use a static
value of min(30, regulatory limit) for max power.
You can see this by looking at how they fill in max_power in the
cfg80211 bands structures.

3. Even when the hardware txpwr limit is retrievable, you can't get it
alone.  You can only get the chip's current regulatory limit, bounded
by the hardware limit.
The hardware limits are also not guaranteed to be static in any
interesting way in the firmware (and in fact, vary per phy, etc)
Meanwhile, the list you are seeing is only updated once per regulatory change.

Given the above, I have doubts it'll be worth trying to get it to
bound the displayed limits by the actual hardware limits (or that it
will even give us real values if I do :P), but i'll take a whack at it
after i fix the VHT issue you are experiencing.

--Dan

On Sun, Dec 24, 2023 at 3:20 PM Daniel Berlin <dberlin@dberlin.org> wrote:
>
> I'll take a look with a pi.  I think I have one around.
>
>
> You are correct on what it should be reporting but it is not.
>
> The actual per-channel hardware power limits are not retrieved and displayed in the list.  They are not part of the default info returned and nothing asks for them.
> They are part of the ratespecs iirc.
>
> I believe I added support for iw link to display them once connected (along with other info we could retrieve).
>
> Sent from Gmail Mobile
>
>
> On Sun, Dec 24, 2023 at 1:29 PM Paul Fertser <fercerpav@gmail.com> wrote:
>>
>> Hi Daniel,
>>
>> On Sat, Dec 23, 2023 at 09:43:55AM -0600, Daniel Berlin wrote:
>> > What you are seeing now is the real state.  The chip and the stack
>> > now have the same domain .  As such, those channels were always
>> > disabled *as far as the chip was concerned*, you just didn't see it
>> > because it didn't display it.  There is code in the driver  to
>> > enable vht40/80 when the regulatory domain is set right.
>>
>> The global regdomain in "iw reg get" changes to the requested one but
>> phy#0 is left at "country 99: DFS-UNSET". However that global domain
>> clearly affects the channel lists as reported by "iw list".
>>
>> 1. 2.4 GHz channels get unlocked as they should (JP channel 14 stays
>> disabled but that's likely irrelevant as it's 802.11b-only)
>>
>> 2. 5 GHz DFS channels get all disabled, no new channels are enabled so
>> VHT40/80 are still not possible
>>
>> That's with clm_blob from Linux firmware tree.
>>
>>
>> Another thing is the per-channel power limits reported. My current
>> understanding is that "iw list" should be showing the currently active
>> limit, that is, the minimum of: generic firmware limit, current
>> regulatory limit, the specific hardware limit. So 30 dBm there looks
>> wrong and inconsistent with the behavior of other drivers, e.g. mt76.
>>
>>
>> Regarding testing on this hardware, raspberrypi docs say that Pi4 can
>> be booted fully over wired network after minimal one-time
>> configuration so that seems to be the easiest option for development.
>>
>> --
>> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
>> mailto:fercerpav@gmail.com

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

[Arend van Spriel]

[-- Attachment #1: Type: text/plain, Size: 13313 bytes --]

On 12/22/2023 6:10 AM, Hector Martin wrote:
> 
> 
> On 2023/12/21 18:57, Arend van Spriel wrote:
>> - SHA-cyfmac-dev-list@infineon.com
>>
>> On 12/21/2023 1:49 AM, Hector Martin wrote:
>>>
>>>
>>> On 2023/12/21 4:36, Arend van Spriel wrote:
>>>> On 12/20/2023 7:14 PM, Hector Martin wrote:
>>>>>
>>>>>
>>>>> On 2023/12/20 19:20, Kalle Valo wrote:
>>>>>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>>>>>
>>>>>>>> Just recently a patch was posted to remove the Infineon list from
>>>>>>>> MAINTAINERS because that company cares so little they have literally
>>>>>>>> stopped accepting emails from us. Meanwhile they are telling their
>>>>>>>> customers that they do not recommend upstream brcmfmac and they should
>>>>>>>> use their downstream driver [1].
>>>>>>>
>>>>>>> Unquestionably broadcom is not helping maintain things, and I think it
>>>>>>> should matter.
>>>>>>>
>>>>>>> As Hector says, they point to their random driver dumps on their site
>>>>>>> that you can't even download unless you are a "Broadcom community
>>>>>>> member" or whatever, and hey - any company that works that way should
>>>>>>> be seen as pretty much hostile to any actual maintenance and proper
>>>>>>> development.
>>>>>>
>>>>>> Sadly this is the normal in the wireless world. All vendors focus on the
>>>>>> latest generation, currently it's Wi-Fi 7, and lose interest on older
>>>>>> generations. And vendors lose focus on the upstream drivers even faster,
>>>>>> usually after a customer project ends.
>>>>>>
>>>>>> So in practise what we try to do is keep the drivers working somehow on
>>>>>> our own, even after the vendors are long gone. If we would deliberately
>>>>>> allow breaking drivers because vendor/corporations don't support us, I
>>>>>> suspect we would have sevaral broken drivers in upstream.
>>>>>>
>>>>>>> If Daniel and Hector are responsive to actual problem reports for the
>>>>>>> changes they cause, I do think that should count a lot.
>>>>>>
>>>>>> Sure, but they could also respect to the review comments. I find Arend's
>>>>>> proposal is reasonable and that's what I would implement in v2. We
>>>>>> (linux-wireless) make abstractions to workaround firmware problems or
>>>>>> interface conflicts all the time, just look at ath10k for example. I
>>>>>> would not be surprised if we need to add even more abstractions to
>>>>>> brcmfmac in the future. And Arend is the expert here, he has best
>>>>>> knowledge of Broadcom devices and I trust him.
>>>>>>
>>>>>> Has anyone even investigated what it would need to implement Arend's
>>>>>> proposal? At least I don't see any indication of that.
>>>>>
>>>>> Of course we can implement it (and we will as we actually got a report
>>>>> of this patch breaking Cypress now, finally).
>>>>>
>>>>> The question was never whether it could be done, we're already doing a
>>>>> bunch of abstractions to deal with just the Broadcom-only side of things
>>>>> too. The point I was trying to make is that we need to *know* what
>>>>> firmware abstractions we need and *why* they are needed. We can't just
>>>>> say, for every change, "well, nobody knows if the existing code works or
>>>>> not, so let's just add an abstraction just in case the change breaks
>>>>> something". As far as anyone involved in the discussions until now could
>>>>> tell, this code was just something some Cypress person dumped upstream,
>>>>> and nobody involved was being responsive to any of our inquiries, so
>>>>> there was no way to be certain it worked at all, whether it was
>>>>> supported in public firmware, or anything else.
>>>>>
>>>>> *Now* that we know the existing code is actually functional and not just
>>>>> dead/broken, and that the WSEC approach is conversely not functional on
>>>>> the Cypress firmwares, it makes sense to introduce an abstraction.
>>>>
>>>> Just a quick look in the git history could have told you that it was not
>>>> just dumped upstream and at least one person was using it and extended
>>>> it for 802.11r support (fast-roaming):
>>>>
>>>>
>>>> author	Paweł Drewniak <czajernia@gmail.com>	2021-08-24 23:13:30 +0100
>>>> committer	Kalle Valo <kvalo@codeaurora.org>	2021-08-29 11:33:07 +0300
>>>> commit	4b51de063d5310f1fb297388b7955926e63e45c9 (patch)
>>>> tree	ba2ccb5cbd055d482a8daa263f5e53531c07667f
>>>> /drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>> parent	81f9ebd43659320a88cae8ed5124c50b4d47ab66 (diff)
>>>> download	wireless-4b51de063d5310f1fb297388b7955926e63e45c9.tar.gz
>>>> brcmfmac: Add WPA3 Personal with FT to supported cipher suites
>>>> This allows the driver to connect to BSSIDs supporting SAE with 802.11r.
>>>> Tested on Raspberry Pi 4 Model B (STA) and UniFi 6LR/OpenWRT 21.02.0-rc2.
>>>> AP was set to 'sae-mixed' (WPA2/3 Personal).
>>>>
>>>> Signed-off-by: Paweł Drewniak <czajernia@gmail.com>
>>>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>>>> Link: https://lore.kernel.org/r/20210824221330.3847139-1-czajernia@gmail.com
>>>
>>> Sure, but we also had user reports of it *not* actually working (maybe
>>> it regressed?). We didn't know whether it was functional with the
>>> linux-firmware blobs in any way, I wanted confirmation of that. And we
>>> also didn't know that the patch *would* break it at all; perhaps the
>>> Cypress firmware had also grown support for the WSEC mechanism.
>>>
>>> That's why I wanted someone to actually confirm the code worked (in some
>>> subset of cases) and the patch didn't, before starting to introduce
>>> conditionals. There is, of course, also the element that the Cypress
>>> side has been long unmaintained, and if nobody is testing/giving
>>> feedback/complaining, perhaps it's better to err on the side of maybe
>>> breaking something and see if that gets someone to come out of the
>>> woodwork if it really breaks, rather than tiptoeing around the code
>>> without knowing what's going on and without anyone actually testing things.
>>
>> That is because you distrust the intent that Cypress was really
>> contributing. They were and I trusted them to not just throw in a
>> feature like WPA3. When Infineon took over they went mute. Upon
>> reviewing your patch (again) I also sent an email to them asking
>> specifically about the status of the sae_password interface. I did not
>> use the mailing list which indeed bounces these days (hence removed
>> them) but the last living soul that I had contact with about a year ago
>> whether they were still comitted to be involved. I guess out of
>> politeness or embarrassment I got confirmation they were and never heard
>> from him again. The query about the sae_password interface is still pending.
> 
> If only corporate acquisition politics didn't repeatedly throw a wrench
> into this one... :/
> 
> This is where we are though, Infineon clearly doesn't care, so it's time
> to move on.
> 
>>> It's not about this *specific* patch, it's about the general situation
>>> of not being able to touch firmware interfaces "just in case Cypress
>>> breaks" being unsustainable in the long term. I wasn't pushing back
>>> because I think this particular one will be hard, I was pushing back
>>> because I can read the tea leaves and see this is not going to end well
>>> if it's the approach we start taking for everything. We *need* someone
>>> to be testing patches on Cypress, we can't just "try not to touch it"
>>> and cross our fingers. That just ends in disaster, we are not going to
>>> succeed in not breaking it either way and it's going to make the driver
>>> worse.
>>
>> I admire you ability of reading tea leaves. You saw the Grim I reckon.
>> Admittedly your responses on every comment from my side (or Kalle for
>> that matter) was polarizing every discussion. That is common way people
>> treat each other nowadays especially online where a conversation is just
>> a pile of text going shit. It does not bring out the best in me either,
>> but it was draining every ounce of energy from me so better end it by
>> stepping out.
> 
> The hilariously outdated kernel development model surely doesn't help
> either (I've stated my opinion on this quite a few times if you've
> followed around) ;)

It is not a fair statement to call the kernel development process 
outdated. It is a vast code base that needs agreed upon steps to keep it 
rolling as it is. Attend a plumbers conference or collaboration summit 
or better become a speaker and vent all your opinions there and have a 
discussion with community members. They are held yearly and maybe over 
the past years things have been introduced that give more churn than 
value and that would be a great topic for discussion. However, it is 
better left outside of the development workflow.

> This stuff gets *really* frustrating when you're trying to improve what
> is, I hope we can all admit, an undermaintained driver (that is not to
> say it's anyone's fault personally), and end up getting held back due to
> everything from coding style nitpicks to people not having the time to
> be responsive. It's just not helpful. It's important to know when to
> step aside and let people actually get stuff done.
> 
> When Daniel started sending me brcmfmac patches downstream, I took a
> look at a few of them, decided he knew what he was doing, and just
> started pulling in his branches wholesale. Was it perfect? No, I had to
> debug at least one regression at one point. But it took me less time to
> do that than it would've to go through the commits with a fine toothed
> comb, so it was clearly the right decision.

With the patch that started it all I simply had another view based on 
trusting my peers. Infineon has been pulling away from brcmfmac off the 
bat, but Cypress was serious enough about the driver not to drop a heap 
of dung on it. Based on that I felt regressions would be around the 
corner if we took it as is.

> That is not to say that should be the standard upstream (we make a point
> of moving fast and breaking things more downstream, since it's a proving
> ground for what eventually will be upstreamed), but I think it does
> demonstrate the kind of delegation ability that is sorely lacking in
> many drivers and subsystems in the kernel these days. Maintainers become
> entrenched in their position, long beyond the point where they have the
> time/motivation/ability to drive the code forward, and end up in the way
> of new people who are trying to make a difference. I think Linus knows
> full well the kernel maintainer community is stagnating.
> 
> That doesn't mean people should step down entirely. But it does mean
> they need to recognize when this is happening and, at least, proactively
> try to bring new people in, instead of just continuing to play a
> gatekeeping role. The role of maintainers should not be that of a wall
> people have to climb over to get their changes in, it should be to guide
> new contributors and help onboard people who can contribute, as peers
> and eventually as future maintainers.
> 
> Kalle, in the other thread you said "this is not fun anymore, this is
> more like a business with requirements and demands coming from
> everywhere.". That's what it feels like to us when our changes get
> rejected because the local vars aren't in reverse Christmas tree order,
> or because our commit messages have "v2:" in them. It feels like some
> manager is trying to justify their position by creating busywork for
> everyone else. Nobody should actually care about any of those things,
> and if they do, they need to step back and really ask themselves how
> they ended up believing that. If the goal is to enforce a reasonable
> shared coding style so things don't spiral into chaos, FFS, let's just
> do what every other project does these days and adopt clang-format. Then
> *all* of us can stop wasting time on these trivialities and go back to
> getting stuff done. And really, nobody cares about commit messages as
> long as the tags are right, the subject line is succinct, and the
> important information is in there. Extra stuff never hurt anyone.

https://docs.kernel.org/process/clang-format.html#clangformat

Enjoy!!

>> I added the ground work for multi-vendor support, but have not decided
>> on the approach to take. Abstract per firmware interface primitive or
>> simply have a cfg80211.c and fwil_types.h per vendor OR implement a
>> vendor-specific cfg80211 callback and override the default callback
>> during the driver attach, ie. in brcmf_fwvid_wcc_attach(). The latter
>> duplicates things, but lean towards that as it may be easier on the
>> long-term. What do your tea leaves tell you ;-)
> 
> FWIW, I was hoping you'd stay on at least as a reviewer. Your
> contributions are valuable. You obviously know the driver and hardware
> much better than most people. I encourage you to, at least, post a v2 of
> the MAINTAINERS patch with yourself as an R: line.
> 
> As far as the actual driver abstraction architecture, I'm going to leave
> it to Daniel to decide what makes the most sense, since he's the one
> introducing new mechanisms for that already. There's always room for
> refactoring later though, depending on the direction things take with
> the vendor split. BTW, clang-format also makes refactoring a lot less
> painful ;)

Refactoring a single driver is not so painful, but rather a nice 
relaxing puzzle ;-)

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

SAE AP on BCM4345/6 (was: Re: Testing bits/080-wifi on BCM4345/6)

[Paul Fertser]

On Sat, Dec 23, 2023 at 01:28:19PM +0300, Paul Fertser wrote:
> 4. AP mode WPA3 SAE starts and beacons but connection to it is
> impossible (probably due to a user error, haven't tested much).

This wasn't supposed to work before [0] so when testing this feature
make sure you run hostapd from git.

For the reference, I haven't tried it with your patches yet and it's
still not working on AP6255 with mainline.

[0] https://w1.fi/cgit/hostap/commit/?id=b089803091cff61e253e09fb560c7ef7a336a611

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com