From: James Prestwood <prestwoj@gmail.com>
To: KeithG <ys3al35l@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
Harry ten Berge <htenberge@gmail.com>,
iwd@lists.linux.dev
Subject: Re: Raspberry Pi 5 and WPA3
Date: Thu, 2 May 2024 07:07:04 -0700 [thread overview]
Message-ID: <129db0c4-d402-480a-ba9a-d28ecbbdacfe@gmail.com> (raw)
In-Reply-To: <CAG17S_MR1ZKkX7nUmb-0K0WAKDSpV8=xSR8ky-wD4uvmwiGiUw@mail.gmail.com>
Hi Keith,
On 5/2/24 6:47 AM, KeithG wrote:
> James,
>
> I tried to connect via my Samsung S23 phone and my desktop with an
> intel card. The desktop uses iwd 2.17 and when I tried to connect via
> iwctl, it did the same thing as the RPi. I suspect my hostapd config,
> but do not know. I can try collecting some logs next week on the
> desktop and the Pi. Which log do you need? '-d something' or an iwmon
> log?
Yeah just a -d IWD log. If you want to capture with iwmon that
definitely can't hurt. For reference, this is the config we use for one
of our SAE autotests:
https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/autotests/testSAE/ssidSAE.conf
>
> Keith
>
> On Thu, May 2, 2024 at 8:09 AM James Prestwood <prestwoj@gmail.com> wrote:
>> Hi Keith,
>>
>> On 5/2/24 5:56 AM, KeithG wrote:
>>> On Tue, Apr 30, 2024 at 7:19 AM KeithG <ys3al35l@gmail.com> wrote:
>>>> On Tue, Apr 30, 2024 at 6:24 AM James Prestwood <prestwoj@gmail.com> wrote:
>>>>> Hi Marcel,
>>>>>
>>>>> On 4/30/24 12:42 AM, Marcel Holtmann wrote:
>>>>>> Hi James,
>>>>>>
>>>>>>>> I'm not sure this is the right place to ask for some assistance, but
>>>>>>>> here we go...
>>>>>>>>
>>>>>>>> I'm the author for a small Raspberry Pi audio image that is
>>>>>>>> specifically targeting Roon.
>>>>>>>> If you're not familiair with Roon: it's an audio streaming platform
>>>>>>>> targeting audiophiles ;-)
>>>>>>>>
>>>>>>>> Anyways, about a year ago I switched from wpa_supplicant to iwd, to
>>>>>>>> full satisfaction.
>>>>>>>> Better and easier integration, and overall a feel of me being in more control.
>>>>>>>>
>>>>>>>> Now, recently I'm having issues with WPA3 support. This is partly
>>>>>>>> related to firmware (it's just so obfuscated how this all works with
>>>>>>>> firmware from broadcom and firmware from cypress :-(
>>>>>>>>
>>>>>>>> And one of those things is that I can't get it to work on the new Pi
>>>>>>>> 5. Specifically IWD reporting this:
>>>>>>>>
>>>>>>>> Apr 29 17:41:41 ropieee5 iwd[275]: src/wiphy.c:wiphy_select_akm()
>>>>>>>> Network is WPA3-Personal...
>>>>>>>> Apr 29 17:41:41 ropieee5 iwd[275]: SAE unsupported: brcmfmac needs
>>>>>>>> CMD_EXTERNAL_AUTH for SAE
>>>>>>>> Apr 29 17:41:41 ropieee5 iwd[275]: src/wiphy.c:wiphy_select_akm()
>>>>>>>> Can't use SAE, trying WPA2
>>>>>>>>
>>>>>>>> Now, the Pi guys point me to the missing CMD_EXTERNAL_AUTH message and
>>>>>>>> advise me to go back to wpa_supplicant. Which is not something I would
>>>>>>>> like to do for various reasons...
>>>>>>>>
>>>>>>>> Do you have any advice for me on what I can do? is this
>>>>>>>> CMD_EXTERNAL_AUTH really related to this and are you planning on
>>>>>>>> implementing this?
>>>>>>> Unfortunately the external auth support is not yet implemented in IWD. The brcmfmac driver itself is rather unique being a fullmac driver. Depending on how you look at it, this on its own is "easier" to support. It handles connecting/roaming all on its own. But then, for some reason, someone didn't want to do SAE/WPA3 on the card itself so they came up with some one-off mechanism to offload that onto userspace. This is one of those things that got put upstream that is a pain for projects like IWD to support IMO. Its something we do need to support eventually, especially given the raspi 5 requires it.
>>>>>> if the Broadcom firmware finally would be able to support external_auth,
>>>>>> then it would be nice, but as seen on recent linux-wireless discussions,
>>>>>> it is unclear who does what. Broadcom wanted to support external_auth,
>>>>>> but then Infineon (the new owner) might be rather using SAE as part of
>>>>>> the firmware. And actually the chip on the RPi5 marks itself as Cypress
>>>>>> and so you it is an unclear story. I think that Raspberry Pi foundation
>>>>>> should get their story straight. Until really recently they shipped a
>>>>>> firmware that couldn’t do SAE and also their drivers couldn’t even do
>>>>>> external_auth and you were stuck with WPA2 only.
>>>>>>
>>>>>> https://holtmann.dev/enabling-wpa3-on-raspberry-pi/
>>>>> I was not aware that it didn't even support it correctly. I figured
>>>>> broadcom was who added it in the first place.
>>>>>> You can use an upstream firmware from linux-firmware and make the RPi5
>>>>>> support WPA3. And as of a few weeks ago, even RPi5 latest Debian was
>>>>>> switching to the upstream firmware.
>>>>>>
>>>>>> On side note, there exists no wpa_supplicant release that really supports
>>>>>> SAE offload properly. You need to back port a lot of patches or hope
>>>>>> that your distro back ported them for you.
>>>>>>
>>>>>> We should actually check if nl80211 tells us that external_auth is
>>>>>> supported by the driver. And if not (which is the case for the Broadcom
>>>>>> upstream driver) send a proper message to users and not lead them into
>>>>>> a wild goose chase.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Marcel
>>>>>>
>>>> FWIW, the most recent update to the RPI Bookworm image has enabled
>>>> this capability:
>>>> # uname -a
>>>> Linux pi5 6.6.28+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1
>>>> (2024-04-22) aarch64 GNU/Linux
>>>>
>>>> # dmesg | grep brcmfmac
>>>> [ 2.195263] brcmfmac: F1 signature read @0x18000000=0x15264345
>>>> [ 2.209946] brcmfmac: brcmf_fw_alloc_request: using
>>>> brcm/brcmfmac43455-sdio for chip BCM4345/6
>>>> [ 2.216566] usbcore: registered new interface driver brcmfmac
>>>> [ 2.384898] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob
>>>> available (err=-2)
>>>> [ 2.385212] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
>>>> wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID
>>>> 01-996384e2
>>>>
>>>> # iw list
>>>> Wiphy phy0
>>>> ...
>>>> 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
>>>>
>>>> This was achieved here with a normal 'apt update ; apt upgrade' routine.
>>>>
>>>> This appears to work for all Pis, now. Even a 32 bit image on a 3b+
>>>> with similar hardware:
>>>> # uname -a
>>>> Linux rpi32 6.6.28+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.28-1+rpt1
>>>> (2024-04-22) armv7l GNU/Linux
>>>> # iw list
>>>> ...
>>>> 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
>>>>
>>>> The PiZero2W does not show this capability with the same 64 bit image
>>>> running as it has different hardware with different firmware:
>>>> # dmesg | grep brcmfmac
>>>> [ 6.051393] brcmfmac: F1 signature read @0x18000000=0x1542a9a6
>>>> [ 6.077172] brcmfmac: brcmf_fw_alloc_request: using
>>>> brcm/brcmfmac43430b0-sdio for chip BCM43430/2
>>>> [ 6.080782] usbcore: registered new interface driver brcmfmac
>>>> [ 6.476401] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob
>>>> available (err=-2)
>>>> [ 6.481953] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/2
>>>> wl0: Mar 31 2022 17:24:51 version 9.88.4.77 (g58bc5cc) FWID
>>>> 01-3b307371
>>>>
>>>> Keith
>>> I got around to testing this a bit tonight. I set up my Pi5 with
>>> hostapd and used this /etc/hostapd/hostapd.conf
>>>
>>> # cat /etc/hostapd/hostapd.conf
>>> # interface and driver
>>> interface=ap0
>>> driver=nl80211
>>>
>>> # WIFI-Config
>>> ssid=SSIDWPA3
>>> channel=7
>>> hw_mode=g
>>> ieee80211n=1
>>> wmm_enabled=1
>>> macaddr_acl=0
>>> auth_algs=1
>>> max_num_sta=10
>>>
>>> wpa=2
>>> wpa_key_mgmt=SAE
>>> rsn_pairwise=CCMP
>>> ieee80211w=2
>>> wpa_passphrase=password
>>> sae_pwe=2
>>>
>>> Form the log, it looks like SAE is enabled and ruinning, but I do not
>>> know what I am looking at.
>>> Using interface ap0 with hwaddr d8:3a:dd:27:6f:a7 and ssid "SSIDWPA3"
>>> ...
>>> SAE: Derive PT - group 19
>>> SAE: SSID - hexdump_ascii(len=8):
>>> 53 53 49 44 57 50 41 33 SSIDWPA3
>>> SAE: password - hexdump_ascii(len=9): [REMOVED]
>>> SAE: pwd-seed - hexdump(len=32): [REMOVED]
>>> SAE: pwd-value (u1 P1) - hexdump(len=48): [REMOVED]
>>> SAE: u1 - hexdump(len=32): [REMOVED]
>>> ...
>>>
>>> I can 'see' it from my other pi running iwd and on my laptop, but I
>>> cannot connect on either. I get nothing in the log. When I type in the
>>> password, I get:
>>>
>>> [iwd]# station wlan0 connect SSIDWPA3
>>> Type the network passphrase for SSIDWPA3 psk.
>>> Passphrase: *********
>>> Operation failed
>> We'll need to see some IWD logs to see whats going on. Also, can you
>> connect from your phone or some other device?
>>
>>> Both Pis show that they have what Marcel noted:
>>>
>>> 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
>>>
>>> Is my config wrong?
>>>
>>> The version of iwd I am running is 2.17 built from git with the latest
>>> commit as of e3f6a2c. The version if hostapd is:
>>> # hostapd -v
>>> hostapd v2.10
>>> User space daemon for IEEE 802.11 AP management,
>>> IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
next prev parent reply other threads:[~2024-05-02 14:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 20:25 Raspberry Pi 5 and WPA3 Harry ten Berge
2024-04-29 21:29 ` James Prestwood
2024-04-30 6:49 ` Harry ten Berge
2024-04-30 7:42 ` Marcel Holtmann
2024-04-30 11:17 ` James Prestwood
2024-04-30 12:19 ` KeithG
2024-04-30 15:42 ` Harry ten Berge
2024-05-02 12:56 ` KeithG
2024-05-02 13:09 ` James Prestwood
2024-05-02 13:47 ` KeithG
2024-05-02 14:07 ` James Prestwood [this message]
2024-05-07 2:33 ` KeithG
2024-05-07 11:55 ` James Prestwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=129db0c4-d402-480a-ba9a-d28ecbbdacfe@gmail.com \
--to=prestwoj@gmail.com \
--cc=htenberge@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=marcel@holtmann.org \
--cc=ys3al35l@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox