Closed iucoen closed 9 months ago
It's working for me, but I've not tried EAP-TLS. Which firmware is this with?
$ strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | grep Ver
$ dmesg | grep Firmware:
It's working for me, but I've not tried EAP-TLS. Which firmware is this with?
$ strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | grep Ver $ dmesg | grep Firmware:
$ strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | grep Ver
43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-lpc-pwropt-43455_ftrs-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv Version: 7.45.241 (1a2f2fa CY) CRC: 959ad1c7 Date: Mon 2021-11-01 00:40:29 PDT Ucode Ver: 1043.2164 FWID 01-703fd60
$ grep Firmware: dmesg.txt
[ 4.954859] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60
That's not our current firmware - we moved to a generic firmware from April 2021 (https://github.com/RPi-Distro/firmware-nonfree/blob/bookworm/debian/config/brcm80211/cypress/cyfmac43455-sdio-standard.bin) because it supports SAE (WPA3) in the firmware, although sadly only with iwd, not wpa_supplicant. There's also a newer trial version, which you can download from here (https://drive.google.com/file/d/13u_Ipf6yUATl38HyVNiHG3H2BVxCzfkB/view?usp=drive_link), that lets wpa_supplicant do the SAE handshake. I'm curious as to whether either of those, particularly the latter, works in your environment.
Note that those chanspec errors are non-fatal - it's complaining about channels that the firmware doesn't support, and at least in my environment it is right not to support them - but annoying. They can be disabled when we're convinced that they don't indicate some real problem.
Is iwd supported yet? Last time I tried the defconfig files did not have the requisite kernel CONFIG_CRYPTO* options enabled.
Configuring Network Manager to use iwd allowed a Pi 4 running that firmware to connect to a WPA3 network. Beyond that, I don't know.
Configuring Network Manager to use iwd allowed a Pi 4 running that firmware to connect to a WPA3 network. Beyond that, I don't know. I had to add these for EAP-TLS to work:
diff --git a/arch/arm64/configs/bcm2712_defconfig b/arch/arm64/configs/bcm2712_defconfig index 5e7a777e9b59..6cb3c1e3a333 100644 --- a/arch/arm64/configs/bcm2712_defconfig +++ b/arch/arm64/configs/bcm2712_defconfig @@ -1625,20 +1625,29 @@ CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_DLM=m +CONFIG_KEYS=y +CONFIG_KEY_DH_OPERATIONS=y CONFIG_SECURITY=y CONFIG_SECURITY_APPARMOR=y CONFIG_LSM="" CONFIG_CRYPTO_USER=m CONFIG_CRYPTO_CRYPTD=m +CONFIG_CRYPTO_RSA=m +CONFIG_CRYPTO_DH=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_ADIANTUM=m CONFIG_CRYPTO_CBC=m +CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CHACHA20POLY1305=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_MD4=m +CONFIG_CRYPTO_MD5=m +CONFIG_CRYPTO_SHA1=m +CONFIG_CRYPTO_SHA256=m +CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_LZ4=m @@ -1658,6 +1667,11 @@ CONFIG_CRYPTO_AES_ARM64_BS=m CONFIG_CRYPTO_SM4_ARM64_CE=m CONFIG_CRYPTO_AES_ARM64_CE_CCM=m # CONFIG_CRYPTO_HW is not set +CONFIG_ASYMMETRIC_KEY_TYPE=y +CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y +CONFIG_X509_CERTIFICATE_PARSER=m +CONFIG_PKCS8_PRIVATE_KEY_PARSER=m +CONFIG_PKCS7_MESSAGE_PARSER=m CONFIG_CRC_ITU_T=y CONFIG_LIBCRC32C=y CONFIG_DMA_CMA=y
Of those, only CONFIG_KEY_DH_OPERATIONS=y
and CONFIG_CRYPTO_DH=m
are non-standard (except for some 'm'/'y' differences).
Are you going to be able to try the other firmwares? Unfortunately my test kit doesn't support EAP-TLS.
Are you going to be able to try the other firmwares? Unfortunately my test kit doesn't support EAP-TLS.
Hi I tried the April firmware. It didn’t solve my problem. I think the problematic commit is 15f000a. After reverting that change I can verify that the April firmware does work with WPA3 Enterprise (in EAP-TLS mode) with iwd.
Of those, only
CONFIG_KEY_DH_OPERATIONS=y
andCONFIG_CRYPTO_DH=m
are non-standard (except for some 'm'/'y' differences).
I only pasted half of the patch earlier (fixed). Here's the second half:
@@ -1658,6 +1667,11 @@ CONFIG_CRYPTO_AES_ARM64_BS=m
CONFIG_CRYPTO_SM4_ARM64_CE=m
CONFIG_CRYPTO_AES_ARM64_CE_CCM=m
# CONFIG_CRYPTO_HW is not set
+CONFIG_ASYMMETRIC_KEY_TYPE=y
+CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
+CONFIG_X509_CERTIFICATE_PARSER=m
+CONFIG_PKCS8_PRIVATE_KEY_PARSER=m
+CONFIG_PKCS7_MESSAGE_PARSER=m
CONFIG_CRC_ITU_T=y
CONFIG_LIBCRC32C=y
Note that those chanspec errors are non-fatal - it's complaining about channels that the firmware doesn't support, and at least in my environment it is right not to support them - but annoying. They can be disabled when we're convinced that they don't indicate some real problem.
FWIW i reported this issue to linux-wireless: https://marc.info/?l=linux-wireless&m=169972111422935&w=2
Note that those chanspec errors are non-fatal - it's complaining about channels that the firmware doesn't support, and at least in my environment it is right not to support them - but annoying. They can be disabled when we're convinced that they don't indicate some real problem.
FWIW i reported this issue to linux-wireless: https://marc.info/?l=linux-wireless&m=169972111422935&w=2
ACK on that "chanspec errors are non-fatal". I believe that the error in brcmf_cfg80211_set_pmk() is legit and that's what's causing my wifi to not work.
I think the problematic line of code is here: https://github.com/raspberrypi/linux/commit/15f000a518a6b226b815b60b76c797cf6adc33df#diff-3d76df104aa1b96e86b7acdaa0609be702f7973c7ac60b9eaa32f99d18f924a2R2490
Basically, if BRCMF_FEAT_FWSUP is enabled, and if the current connection is not using Pre-shared key (!sme->crypto.psk), then it sets profile->use_fwsup to BRCMF_PROFILE_FWSUP_NONE. Later brcmf_cfg80211_set_pmk() fails because it expects profile->use_fwsup to be BRCMF_PROFILE_FWSUP_1X.
I think patch 15f000a518a6b226b815b60b76c797cf6adc33df basically assumes that the connection is either PSK, or NONE, and didn't handle the third possibility that it could be 802.1X.
Configuring Network Manager to use iwd allowed a Pi 4 running that firmware to connect to a WPA3 network. Beyond that, I don't know. I had to add these for EAP-TLS to work:
I created PR https://github.com/raspberrypi/linux/pull/5974 for this.
Thank you for all your work on this problem.
Describe the bug
Steps to reproduce the behaviour
Boot up, error happens as soon as wpa_supplicant starts.
Device (s)
Raspberry Pi 5
System
I use gentoo linux. Kernel version 6.6.16-v8-16k+. For WIFI I'm using wpa_supplicant in EAP-TLS mode.
Logs
dmesg
Additional context
No response