[Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[KeithG]

I know brcmfmac is a pain to deal with on many fronts. The current
firmware installed by RPiOS in bookworm as of:

Linux 6.6.31+rpt-rpi-v8 RPiOS-bookworm aarch64 (64bit)

is:
[   65.894288] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID
01-996384e2
iwlist shows:
        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 driver does not seem to work with iwd nor wpa_supplicant to
connect to an SAE3-Personal network. To get it to work with
wpa_supplicant, I had to follow the instructions in this link:
https://github.com/raspberrypi/linux/pull/5945
It shows that it has been merged into the kernel. The new firmware
forces SAE authentication to the AUTHENTICATE command, apparently.

[   65.764656] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID
01-b677b91b
iwlist shows:
...
 Device supports SAE with AUTHENTICATE command
...
        Supported extended features:
                * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
                * [ DFS_OFFLOAD ]: DFS offload

With this driver and the latest wpa_supplicant (built from git), I can
connect to an SAE3/Personal AP.

I am not a dev but can build and test stuff on my setup. As I
understand it, since the new brcmfmac firmware requires the SAE
authentication to be done outside of the kernel and that iwd does not
yet support this functionality.
Is there anything I can do to support the addition of this
functionality to iwd? We develop on the RPi and we are stuck with the
brcmfmac cards and use connman/iwd for our connectivity.

Keith

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[James Prestwood]

Hi Keith,

On 8/4/24 10:08 AM, KeithG wrote:
> I know brcmfmac is a pain to deal with on many fronts. The current
> firmware installed by RPiOS in bookworm as of:
>
> Linux 6.6.31+rpt-rpi-v8 RPiOS-bookworm aarch64 (64bit)
>
> is:
> [   65.894288] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
> wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID
> 01-996384e2
> iwlist shows:
>          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 driver does not seem to work with iwd nor wpa_supplicant to
> connect to an SAE3-Personal network. To get it to work with
> wpa_supplicant, I had to follow the instructions in this link:
> https://github.com/raspberrypi/linux/pull/5945
> It shows that it has been merged into the kernel. The new firmware
> forces SAE authentication to the AUTHENTICATE command, apparently.
>
> [   65.764656] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
> wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID
> 01-b677b91b
> iwlist shows:
> ...
>   Device supports SAE with AUTHENTICATE command

So this is interesting... IWD does not expect a fullmac card to support 
AUTHENTICATE but if this is the direction brcmfmac is going I guess we 
can support it. This is such a mess though and brcmfmac just needs to 
decide what they are doing. This just makes things even more complicated 
as we now have 3 (?) ways to do SAE just on brcmfmac.

I think IWD is getting very confused with this newly added support. 
Could you get a wiphy dump with iwmon with this new kernel/firmware so I 
can see what exactly its saying it supports and what it doesn't. You can 
do this by running iwmon:

iwmon --nortnl --noscan -w iwmon.pcap

Then starting IWD.

> ...
>          Supported extended features:
>                  * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
>                  * [ DFS_OFFLOAD ]: DFS offload
>
> With this driver and the latest wpa_supplicant (built from git), I can
> connect to an SAE3/Personal AP.
>
> I am not a dev but can build and test stuff on my setup. As I
> understand it, since the new brcmfmac firmware requires the SAE
> authentication to be done outside of the kernel and that iwd does not
> yet support this functionality.
> Is there anything I can do to support the addition of this
> functionality to iwd? We develop on the RPi and we are stuck with the
> brcmfmac cards and use connman/iwd for our connectivity.
>
> Keith
>

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[Denis Kenzior]

Hi James,

>> ...
>>   Device supports SAE with AUTHENTICATE command
> 
> So this is interesting... IWD does not expect a fullmac card to support 
> AUTHENTICATE but if this is the direction brcmfmac is going I guess we can 

That's because iw output is misleading.  This driver uses CMD_EXTERNAL_AUTH to 
tell iwd/wpa_s to transfer SAE authenticate frames via CMD_FRAME (similar to how 
iwd does FT-Auth frames).

Unfortunately the kernel never dedicated an actual capability bit to tell 
userspace that CMD_EXTERNAL_AUTH is being used.  They just reuse the generic 
FEATURE_SAE.

> support it. This is such a mess though and brcmfmac just needs to decide what 
> they are doing. This just makes things even more complicated as we now have 3 
> (?) ways to do SAE just on brcmfmac.

Its still just 2, SAE_OFFLOAD and EXTERNAL_AUTH

Regards,
-Denis

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[KeithG]

On Mon, Aug 5, 2024 at 8:56 AM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi James,
>
> >> ...
> >>   Device supports SAE with AUTHENTICATE command
> >
> > So this is interesting... IWD does not expect a fullmac card to support
> > AUTHENTICATE but if this is the direction brcmfmac is going I guess we can
>
> That's because iw output is misleading.  This driver uses CMD_EXTERNAL_AUTH to
> tell iwd/wpa_s to transfer SAE authenticate frames via CMD_FRAME (similar to how
> iwd does FT-Auth frames).
>
> Unfortunately the kernel never dedicated an actual capability bit to tell
> userspace that CMD_EXTERNAL_AUTH is being used.  They just reuse the generic
> FEATURE_SAE.
>
> > support it. This is such a mess though and brcmfmac just needs to decide what
> > they are doing. This just makes things even more complicated as we now have 3
> > (?) ways to do SAE just on brcmfmac.
>
> Its still just 2, SAE_OFFLOAD and EXTERNAL_AUTH
>
> Regards,
> -Denis
James,

Sorry it took so long, but I needed time to build a kernel with the
nlmon module... PiOS does not include it.
THis is with kernel 6.6.44 running on a Pi3B+

The full iw list:
# iw list
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] (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 (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) (radar detection)
            * 5280 MHz [56] (20.0 dBm) (radar detection)
            * 5300 MHz [60] (20.0 dBm) (radar detection)
            * 5320 MHz [64] (20.0 dBm) (radar detection)
            * 5500 MHz [100] (20.0 dBm) (radar detection)
            * 5520 MHz [104] (20.0 dBm) (radar detection)
            * 5540 MHz [108] (20.0 dBm) (radar detection)
            * 5560 MHz [112] (20.0 dBm) (radar detection)
            * 5580 MHz [116] (20.0 dBm) (radar detection)
            * 5600 MHz [120] (20.0 dBm) (radar detection)
            * 5620 MHz [124] (20.0 dBm) (radar detection)
            * 5640 MHz [128] (20.0 dBm) (radar detection)
            * 5660 MHz [132] (20.0 dBm) (radar detection)
            * 5680 MHz [136] (20.0 dBm) (radar detection)
            * 5700 MHz [140] (20.0 dBm) (radar detection)
            * 5720 MHz [144] (20.0 dBm) (radar detection)
            * 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 SAE with AUTHENTICATE command
    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 0xb0 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
        * [ DFS_OFFLOAD ]: DFS offload

this is what dmesg shows:
# dmesg | grep brcmfmac
[   65.358538] brcmfmac: F1 signature read @0x18000000=0x15264345
[   65.372353] brcmfmac: brcmf_fw_alloc_request: using
brcm/brcmfmac43455-sdio for chip BCM4345/6
[   65.411731] usbcore: registered new interface driver brcmfmac
[   65.686557] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob
available (err=-2)
[   65.687105] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID
01-b677b91b

The pcap is uploaded to my gdrive:
https://drive.google.com/file/d/1vIuje60MGFPklcXtSNMi9-IOlV_6sBJ8/view?usp=drivesdk

Hopefully, this helps to get started.

Keith

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[Denis Kenzior]

Hi Keith,

>      Supported extended features:
>          * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
>          * [ DFS_OFFLOAD ]: DFS offload
> 

<snip>

> 
> The pcap is uploaded to my gdrive:
> https://drive.google.com/file/d/1vIuje60MGFPklcXtSNMi9-IOlV_6sBJ8/view?usp=drivesdk

What is the PCAP supposed to show?  There's no Connection attempt in there.

> 
> Hopefully, this helps to get started.
> 

Anyway, I was curious and snooped on wpa_s from git trying to connect to an 
iPhone 12 Personal Hotspot (Maximum Compatibility option off, so it uses SAE). 
Not a pretty sight.  Firmware fails with errno=-52, Invalid exchange.  Has 
anyone from RPI team actually tested this firmware before pushing it out?

I also tried the old firmware with SAE_OFFLOAD bits, and that doesn't work with 
wpa_s or iwd either.

Until someone sends me a iwmon trace showing CMD_EXTERNAL_AUTH exchange working 
on an WPA3-Personal Only network, I remain skeptical that any of the Cypress 
firmwares actually work.

Regards,
-Denis

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[KeithG]

On Sun, Aug 11, 2024 at 2:38 PM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Keith,
>
> >      Supported extended features:
> >          * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
> >          * [ DFS_OFFLOAD ]: DFS offload
> >
>
> <snip>
>
> >
> > The pcap is uploaded to my gdrive:
> > https://drive.google.com/file/d/1vIuje60MGFPklcXtSNMi9-IOlV_6sBJ8/view?usp=drivesdk
>
> What is the PCAP supposed to show?  There's no Connection attempt in there.
>
> >
> > Hopefully, this helps to get started.
> >
>
> Anyway, I was curious and snooped on wpa_s from git trying to connect to an
> iPhone 12 Personal Hotspot (Maximum Compatibility option off, so it uses SAE).
> Not a pretty sight.  Firmware fails with errno=-52, Invalid exchange.  Has
> anyone from RPI team actually tested this firmware before pushing it out?
>
> I also tried the old firmware with SAE_OFFLOAD bits, and that doesn't work with
> wpa_s or iwd either.
>
> Until someone sends me a iwmon trace showing CMD_EXTERNAL_AUTH exchange working
> on an WPA3-Personal Only network, I remain skeptical that any of the Cypress
> firmwares actually work.
>
> Regards,
> -Denis

Denis,

I did not attempt a connect with that first log. I misunderstood what
James was asking for. I tried connecting
with my Samsung phone and was able to connect so it seems that the AP
is working and allows a
connection from my phone.

I tried to connect from the Pi with iwctl:
https://drive.google.com/file/d/1f1jnD0EUOJSaJXd8l7uYG9nisAxCPeo4/view?usp=drivesdk

I uninstalled iwd, installed wpa_supplicant (built from git) rebooted
and tried to connect with connman and collected another pcap and it
did not connect:
https://drive.google.com/file/d/1zuVSF0xu4Nk2fN9ketBSv1tiquT-Sc-p/view?usp=drivesdk

I then tried from wpa_cli and did not connect. I tried again with a
wpa_supplicant.conf and also could not connect.

Now I am trying to figure out what I did to allow this connection to a
sae AP... Now that I have nlmon
module and iwmon, I will see if I can re-connect, somehow.
The brcmfmac is such a pain.
When I get a wpa3/SAE connection, I will make a pcap and post it.
I actually was able to make one with wpa_supplicant once and actually
passed data, but it does not seem to work today.

Keith

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[James Prestwood]

Hi Keith,

On 8/11/24 6:19 PM, KeithG wrote:
> On Sun, Aug 11, 2024 at 2:38 PM Denis Kenzior <denkenz@gmail.com> wrote:
>> Hi Keith,
>>
>>>       Supported extended features:
>>>           * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
>>>           * [ DFS_OFFLOAD ]: DFS offload
>>>
>> <snip>
>>
>>> The pcap is uploaded to my gdrive:
>>> https://drive.google.com/file/d/1vIuje60MGFPklcXtSNMi9-IOlV_6sBJ8/view?usp=drivesdk
>> What is the PCAP supposed to show?  There's no Connection attempt in there.
>>
>>> Hopefully, this helps to get started.
>>>
>> Anyway, I was curious and snooped on wpa_s from git trying to connect to an
>> iPhone 12 Personal Hotspot (Maximum Compatibility option off, so it uses SAE).
>> Not a pretty sight.  Firmware fails with errno=-52, Invalid exchange.  Has
>> anyone from RPI team actually tested this firmware before pushing it out?
>>
>> I also tried the old firmware with SAE_OFFLOAD bits, and that doesn't work with
>> wpa_s or iwd either.
>>
>> Until someone sends me a iwmon trace showing CMD_EXTERNAL_AUTH exchange working
>> on an WPA3-Personal Only network, I remain skeptical that any of the Cypress
>> firmwares actually work.
>>
>> Regards,
>> -Denis
> Denis,
>
> I did not attempt a connect with that first log. I misunderstood what
> James was asking for.

You didn't misunderstand :) I was confused by what I thought brcmfmac 
supported but Denis pointed out that the "Device supports SAE with 
AUTHENTICATE command" only mean NL80211_FEATURE_SAE was set, not that 
CMD_AUTHENTICATE is actually supported (really dumb and confusing, I know).

What is interesting though is even in your pcap CMD_EXTERNAL_AUTH isn't 
showing up as a supported command.

     Supported Commands:
         New Interface [7]
         Set Interface [6]
         New Key [11]
         Start AP [15]
         Join IBSS [43]
         Set PMKSA [52]
         Del PMKSA [53]
         Flush PMKSA [54]
         Remain on Channel [55]
         Frame [59]
         Set Wiphy Netns [49]
         Set Channel [65]
         Start Sched Scan [75]
         Start P2P Device [89]
         Connect [46]
         Disconnect [48]
         Crit Protocol Start [98]
         Crit Protocol Stop [99]
         Update Connect Params [122]

So I'm even more confused now. But as Denis said, we do need a iwmon 
pcap of wpa_supplicant working I think to see how its actually 
connecting successfully.

Thanks,

James

>   I tried connecting
> with my Samsung phone and was able to connect so it seems that the AP
> is working and allows a
> connection from my phone.
>
> I tried to connect from the Pi with iwctl:
> https://drive.google.com/file/d/1f1jnD0EUOJSaJXd8l7uYG9nisAxCPeo4/view?usp=drivesdk
>
> I uninstalled iwd, installed wpa_supplicant (built from git) rebooted
> and tried to connect with connman and collected another pcap and it
> did not connect:
> https://drive.google.com/file/d/1zuVSF0xu4Nk2fN9ketBSv1tiquT-Sc-p/view?usp=drivesdk
>
> I then tried from wpa_cli and did not connect. I tried again with a
> wpa_supplicant.conf and also could not connect.
>
> Now I am trying to figure out what I did to allow this connection to a
> sae AP... Now that I have nlmon
> module and iwmon, I will see if I can re-connect, somehow.
> The brcmfmac is such a pain.
> When I get a wpa3/SAE connection, I will make a pcap and post it.
> I actually was able to make one with wpa_supplicant once and actually
> passed data, but it does not seem to work today.
>
> Keith

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[KeithG]

On Mon, Aug 12, 2024 at 6:36 AM James Prestwood <prestwoj@gmail.com> wrote:
>
> Hi Keith,
>
> On 8/11/24 6:19 PM, KeithG wrote:
> > On Sun, Aug 11, 2024 at 2:38 PM Denis Kenzior <denkenz@gmail.com> wrote:
> >> Hi Keith,
> >>
> >>>       Supported extended features:
> >>>           * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
> >>>           * [ DFS_OFFLOAD ]: DFS offload
> >>>
> >> <snip>
> >>
> >>> The pcap is uploaded to my gdrive:
> >>> https://drive.google.com/file/d/1vIuje60MGFPklcXtSNMi9-IOlV_6sBJ8/view?usp=drivesdk
> >> What is the PCAP supposed to show?  There's no Connection attempt in there.
> >>
> >>> Hopefully, this helps to get started.
> >>>
> >> Anyway, I was curious and snooped on wpa_s from git trying to connect to an
> >> iPhone 12 Personal Hotspot (Maximum Compatibility option off, so it uses SAE).
> >> Not a pretty sight.  Firmware fails with errno=-52, Invalid exchange.  Has
> >> anyone from RPI team actually tested this firmware before pushing it out?
> >>
> >> I also tried the old firmware with SAE_OFFLOAD bits, and that doesn't work with
> >> wpa_s or iwd either.
> >>
> >> Until someone sends me a iwmon trace showing CMD_EXTERNAL_AUTH exchange working
> >> on an WPA3-Personal Only network, I remain skeptical that any of the Cypress
> >> firmwares actually work.
> >>
> >> Regards,
> >> -Denis
> > Denis,
> >
> > I did not attempt a connect with that first log. I misunderstood what
> > James was asking for.
>
> You didn't misunderstand :) I was confused by what I thought brcmfmac
> supported but Denis pointed out that the "Device supports SAE with
> AUTHENTICATE command" only mean NL80211_FEATURE_SAE was set, not that
> CMD_AUTHENTICATE is actually supported (really dumb and confusing, I know).
>
> What is interesting though is even in your pcap CMD_EXTERNAL_AUTH isn't
> showing up as a supported command.
>
>      Supported Commands:
>          New Interface [7]
>          Set Interface [6]
>          New Key [11]
>          Start AP [15]
>          Join IBSS [43]
>          Set PMKSA [52]
>          Del PMKSA [53]
>          Flush PMKSA [54]
>          Remain on Channel [55]
>          Frame [59]
>          Set Wiphy Netns [49]
>          Set Channel [65]
>          Start Sched Scan [75]
>          Start P2P Device [89]
>          Connect [46]
>          Disconnect [48]
>          Crit Protocol Start [98]
>          Crit Protocol Stop [99]
>          Update Connect Params [122]
>
> So I'm even more confused now. But as Denis said, we do need a iwmon
> pcap of wpa_supplicant working I think to see how its actually
> connecting successfully.
>
> Thanks,
>
> James
>
> >   I tried connecting
> > with my Samsung phone and was able to connect so it seems that the AP
> > is working and allows a
> > connection from my phone.
> >
> > I tried to connect from the Pi with iwctl:
> > https://drive.google.com/file/d/1f1jnD0EUOJSaJXd8l7uYG9nisAxCPeo4/view?usp=drivesdk
> >
> > I uninstalled iwd, installed wpa_supplicant (built from git) rebooted
> > and tried to connect with connman and collected another pcap and it
> > did not connect:
> > https://drive.google.com/file/d/1zuVSF0xu4Nk2fN9ketBSv1tiquT-Sc-p/view?usp=drivesdk
> >
> > I then tried from wpa_cli and did not connect. I tried again with a
> > wpa_supplicant.conf and also could not connect.
> >
> > Now I am trying to figure out what I did to allow this connection to a
> > sae AP... Now that I have nlmon
> > module and iwmon, I will see if I can re-connect, somehow.
> > The brcmfmac is such a pain.
> > When I get a wpa3/SAE connection, I will make a pcap and post it.
> > I actually was able to make one with wpa_supplicant once and actually
> > passed data, but it does not seem to work today.
> >
> > Keith

I am back at this. Messed around for a *lot* trying to get it to
connect via wpa_cli and connman and was unable to get it to connect. I
find both connman and wpa_supplicant so tough to figure out what I am
supposed to do to get it to work. I was able to, once, get wpa_cli to
connect via wpa3 a while back, but no more. It does not appear that
the current git version nor the default version of connman allow an
SAE connection on the Pi...

Finally, I was able to get it to connect using the current, default
RPiOS wpa_supplicant and nmcli on a Pi5. No purpose built packages.
just the defaults. Now to see if I can get it to work on the one I
built using the later kernel that I built with the nlmon module. If I
have luck, I'll post a log.

On the hostapd computer:
Aug 17 15:36:25 jackson hostapd[2204]: ap0: AP-STA-CONNECTED d8:3a:dd:d2:ae:3c
Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c
RADIUS: starting accounting session ACB7F795BBC8FF5E
Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c WPA:
pairwise key handshake completed (RSN)
Aug 17 15:36:25 jackson hostapd[2204]: ap0: EAPOL-4WAY-HS-COMPLETED
d8:3a:dd:d2:ae:3c
Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c
RADIUS: starting accounting session ACB7F795BBC8FF5E
Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c WPA:
pairwise key handshake completed (RSN)

and on the Pi:
Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: Trying to associate
with SSID 'deskSAE'
Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.4925]
device (wlan0): supplicant interface state: scanning -> associating
Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.4925]
device (p2p-dev-wlan0): supplicant management interface state:
scanning -> a>
Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: Associated with
d8:3a:dd:60:a3:0c
Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0:
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: WPA: Key negotiation
completed with d8:3a:dd:60:a3:0c [PTK=CCMP GTK=CCMP]
Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: CTRL-EVENT-CONNECTED -
Connection to d8:3a:dd:60:a3:0c completed [id=0 id_str=]
Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6431]
device (wlan0): supplicant interface state: associating -> completed
Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6432]
device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure)
successfu>
Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6433]
device (p2p-dev-wlan0): supplicant management interface state:
associating ->
Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6441]
device (wlan0): state change: config -> ip-config (reason 'none',
sys-iface->
Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6452]
dhcp4 (wlan0): activation: beginning transaction (timeout in 45
seconds)
Aug 17 15:36:25 pi5 avahi-daemon[542]: Registering new address record
for fe80::d8bd:98f9:b458:1f79 on wlan0.*.
Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6629]
dhcp4 (wlan0): state changed new lease, address=192.168.5.177

root@pi5(rw):~# wpa_supplicant -v
wpa_supplicant v2.10
Copyright (c) 2003-2022, Jouni Malinen <j@w1.fi> and contributors
root@pi5(rw):~# NetworkManager -V
1.42.4

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[KeithG]

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

On Sat, Aug 17, 2024 at 3:49 PM KeithG <ys3al35l@gmail.com> wrote:
>
> On Mon, Aug 12, 2024 at 6:36 AM James Prestwood <prestwoj@gmail.com> wrote:
> >
> > Hi Keith,
> >
> > On 8/11/24 6:19 PM, KeithG wrote:
> > > On Sun, Aug 11, 2024 at 2:38 PM Denis Kenzior <denkenz@gmail.com> wrote:
> > >> Hi Keith,
> > >>
> > >>>       Supported extended features:
> > >>>           * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
> > >>>           * [ DFS_OFFLOAD ]: DFS offload
> > >>>
> > >> <snip>
> > >>
> > >>> The pcap is uploaded to my gdrive:
> > >>> https://drive.google.com/file/d/1vIuje60MGFPklcXtSNMi9-IOlV_6sBJ8/view?usp=drivesdk
> > >> What is the PCAP supposed to show?  There's no Connection attempt in there.
> > >>
> > >>> Hopefully, this helps to get started.
> > >>>
> > >> Anyway, I was curious and snooped on wpa_s from git trying to connect to an
> > >> iPhone 12 Personal Hotspot (Maximum Compatibility option off, so it uses SAE).
> > >> Not a pretty sight.  Firmware fails with errno=-52, Invalid exchange.  Has
> > >> anyone from RPI team actually tested this firmware before pushing it out?
> > >>
> > >> I also tried the old firmware with SAE_OFFLOAD bits, and that doesn't work with
> > >> wpa_s or iwd either.
> > >>
> > >> Until someone sends me a iwmon trace showing CMD_EXTERNAL_AUTH exchange working
> > >> on an WPA3-Personal Only network, I remain skeptical that any of the Cypress
> > >> firmwares actually work.
> > >>
> > >> Regards,
> > >> -Denis
> > > Denis,
> > >
> > > I did not attempt a connect with that first log. I misunderstood what
> > > James was asking for.
> >
> > You didn't misunderstand :) I was confused by what I thought brcmfmac
> > supported but Denis pointed out that the "Device supports SAE with
> > AUTHENTICATE command" only mean NL80211_FEATURE_SAE was set, not that
> > CMD_AUTHENTICATE is actually supported (really dumb and confusing, I know).
> >
> > What is interesting though is even in your pcap CMD_EXTERNAL_AUTH isn't
> > showing up as a supported command.
> >
> >      Supported Commands:
> >          New Interface [7]
> >          Set Interface [6]
> >          New Key [11]
> >          Start AP [15]
> >          Join IBSS [43]
> >          Set PMKSA [52]
> >          Del PMKSA [53]
> >          Flush PMKSA [54]
> >          Remain on Channel [55]
> >          Frame [59]
> >          Set Wiphy Netns [49]
> >          Set Channel [65]
> >          Start Sched Scan [75]
> >          Start P2P Device [89]
> >          Connect [46]
> >          Disconnect [48]
> >          Crit Protocol Start [98]
> >          Crit Protocol Stop [99]
> >          Update Connect Params [122]
> >
> > So I'm even more confused now. But as Denis said, we do need a iwmon
> > pcap of wpa_supplicant working I think to see how its actually
> > connecting successfully.
> >
> > Thanks,
> >
> > James
> >
> > >   I tried connecting
> > > with my Samsung phone and was able to connect so it seems that the AP
> > > is working and allows a
> > > connection from my phone.
> > >
> > > I tried to connect from the Pi with iwctl:
> > > https://drive.google.com/file/d/1f1jnD0EUOJSaJXd8l7uYG9nisAxCPeo4/view?usp=drivesdk
> > >
> > > I uninstalled iwd, installed wpa_supplicant (built from git) rebooted
> > > and tried to connect with connman and collected another pcap and it
> > > did not connect:
> > > https://drive.google.com/file/d/1zuVSF0xu4Nk2fN9ketBSv1tiquT-Sc-p/view?usp=drivesdk
> > >
> > > I then tried from wpa_cli and did not connect. I tried again with a
> > > wpa_supplicant.conf and also could not connect.
> > >
> > > Now I am trying to figure out what I did to allow this connection to a
> > > sae AP... Now that I have nlmon
> > > module and iwmon, I will see if I can re-connect, somehow.
> > > The brcmfmac is such a pain.
> > > When I get a wpa3/SAE connection, I will make a pcap and post it.
> > > I actually was able to make one with wpa_supplicant once and actually
> > > passed data, but it does not seem to work today.
> > >
> > > Keith
>
> I am back at this. Messed around for a *lot* trying to get it to
> connect via wpa_cli and connman and was unable to get it to connect. I
> find both connman and wpa_supplicant so tough to figure out what I am
> supposed to do to get it to work. I was able to, once, get wpa_cli to
> connect via wpa3 a while back, but no more. It does not appear that
> the current git version nor the default version of connman allow an
> SAE connection on the Pi...
>
> Finally, I was able to get it to connect using the current, default
> RPiOS wpa_supplicant and nmcli on a Pi5. No purpose built packages.
> just the defaults. Now to see if I can get it to work on the one I
> built using the later kernel that I built with the nlmon module. If I
> have luck, I'll post a log.
>
> On the hostapd computer:
> Aug 17 15:36:25 jackson hostapd[2204]: ap0: AP-STA-CONNECTED d8:3a:dd:d2:ae:3c
> Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c
> RADIUS: starting accounting session ACB7F795BBC8FF5E
> Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c WPA:
> pairwise key handshake completed (RSN)
> Aug 17 15:36:25 jackson hostapd[2204]: ap0: EAPOL-4WAY-HS-COMPLETED
> d8:3a:dd:d2:ae:3c
> Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c
> RADIUS: starting accounting session ACB7F795BBC8FF5E
> Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c WPA:
> pairwise key handshake completed (RSN)
>
> and on the Pi:
> Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: Trying to associate
> with SSID 'deskSAE'
> Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.4925]
> device (wlan0): supplicant interface state: scanning -> associating
> Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.4925]
> device (p2p-dev-wlan0): supplicant management interface state:
> scanning -> a>
> Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: Associated with
> d8:3a:dd:60:a3:0c
> Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0:
> CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
> Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: WPA: Key negotiation
> completed with d8:3a:dd:60:a3:0c [PTK=CCMP GTK=CCMP]
> Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: CTRL-EVENT-CONNECTED -
> Connection to d8:3a:dd:60:a3:0c completed [id=0 id_str=]
> Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6431]
> device (wlan0): supplicant interface state: associating -> completed
> Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6432]
> device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure)
> successfu>
> Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6433]
> device (p2p-dev-wlan0): supplicant management interface state:
> associating ->
> Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6441]
> device (wlan0): state change: config -> ip-config (reason 'none',
> sys-iface->
> Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6452]
> dhcp4 (wlan0): activation: beginning transaction (timeout in 45
> seconds)
> Aug 17 15:36:25 pi5 avahi-daemon[542]: Registering new address record
> for fe80::d8bd:98f9:b458:1f79 on wlan0.*.
> Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6629]
> dhcp4 (wlan0): state changed new lease, address=192.168.5.177
>
> root@pi5(rw):~# wpa_supplicant -v
> wpa_supplicant v2.10
> Copyright (c) 2003-2022, Jouni Malinen <j@w1.fi> and contributors
> root@pi5(rw):~# NetworkManager -V
> 1.42.4

So with that same configuration but on the Pi3B+ running the kernel
with the proper module, I was able to get a pcap of a connection to an
wpa3/sae SSID.
It is attached. So, the current default install on the RPis that run
the brcmfmac card identified as this:

[    6.473673] brcmfmac: brcmf_fw_alloc_request: using
brcm/brcmfmac43455-sdio for chip BCM4345/6
[    6.841681] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID
01-b677b91b

will connect to an SAE authenticated ssid with nmcli and wpa_supplicant

Keith

[-- Attachment #2: iwmon_sae.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 356894 bytes --]

Re: [Request] iwd to support brcmfmac 'SAE with AUTHENTICATE'

[KeithG]

On Sat, Aug 17, 2024 at 5:03 PM KeithG <ys3al35l@gmail.com> wrote:
>
> On Sat, Aug 17, 2024 at 3:49 PM KeithG <ys3al35l@gmail.com> wrote:
> >
> > On Mon, Aug 12, 2024 at 6:36 AM James Prestwood <prestwoj@gmail.com> wrote:
> > >
> > > Hi Keith,
> > >
> > > On 8/11/24 6:19 PM, KeithG wrote:
> > > > On Sun, Aug 11, 2024 at 2:38 PM Denis Kenzior <denkenz@gmail.com> wrote:
> > > >> Hi Keith,
> > > >>
> > > >>>       Supported extended features:
> > > >>>           * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
> > > >>>           * [ DFS_OFFLOAD ]: DFS offload
> > > >>>
> > > >> <snip>
> > > >>
> > > >>> The pcap is uploaded to my gdrive:
> > > >>> https://drive.google.com/file/d/1vIuje60MGFPklcXtSNMi9-IOlV_6sBJ8/view?usp=drivesdk
> > > >> What is the PCAP supposed to show?  There's no Connection attempt in there.
> > > >>
> > > >>> Hopefully, this helps to get started.
> > > >>>
> > > >> Anyway, I was curious and snooped on wpa_s from git trying to connect to an
> > > >> iPhone 12 Personal Hotspot (Maximum Compatibility option off, so it uses SAE).
> > > >> Not a pretty sight.  Firmware fails with errno=-52, Invalid exchange.  Has
> > > >> anyone from RPI team actually tested this firmware before pushing it out?
> > > >>
> > > >> I also tried the old firmware with SAE_OFFLOAD bits, and that doesn't work with
> > > >> wpa_s or iwd either.
> > > >>
> > > >> Until someone sends me a iwmon trace showing CMD_EXTERNAL_AUTH exchange working
> > > >> on an WPA3-Personal Only network, I remain skeptical that any of the Cypress
> > > >> firmwares actually work.
> > > >>
> > > >> Regards,
> > > >> -Denis
> > > > Denis,
> > > >
> > > > I did not attempt a connect with that first log. I misunderstood what
> > > > James was asking for.
> > >
> > > You didn't misunderstand :) I was confused by what I thought brcmfmac
> > > supported but Denis pointed out that the "Device supports SAE with
> > > AUTHENTICATE command" only mean NL80211_FEATURE_SAE was set, not that
> > > CMD_AUTHENTICATE is actually supported (really dumb and confusing, I know).
> > >
> > > What is interesting though is even in your pcap CMD_EXTERNAL_AUTH isn't
> > > showing up as a supported command.
> > >
> > >      Supported Commands:
> > >          New Interface [7]
> > >          Set Interface [6]
> > >          New Key [11]
> > >          Start AP [15]
> > >          Join IBSS [43]
> > >          Set PMKSA [52]
> > >          Del PMKSA [53]
> > >          Flush PMKSA [54]
> > >          Remain on Channel [55]
> > >          Frame [59]
> > >          Set Wiphy Netns [49]
> > >          Set Channel [65]
> > >          Start Sched Scan [75]
> > >          Start P2P Device [89]
> > >          Connect [46]
> > >          Disconnect [48]
> > >          Crit Protocol Start [98]
> > >          Crit Protocol Stop [99]
> > >          Update Connect Params [122]
> > >
> > > So I'm even more confused now. But as Denis said, we do need a iwmon
> > > pcap of wpa_supplicant working I think to see how its actually
> > > connecting successfully.
> > >
> > > Thanks,
> > >
> > > James
> > >
> > > >   I tried connecting
> > > > with my Samsung phone and was able to connect so it seems that the AP
> > > > is working and allows a
> > > > connection from my phone.
> > > >
> > > > I tried to connect from the Pi with iwctl:
> > > > https://drive.google.com/file/d/1f1jnD0EUOJSaJXd8l7uYG9nisAxCPeo4/view?usp=drivesdk
> > > >
> > > > I uninstalled iwd, installed wpa_supplicant (built from git) rebooted
> > > > and tried to connect with connman and collected another pcap and it
> > > > did not connect:
> > > > https://drive.google.com/file/d/1zuVSF0xu4Nk2fN9ketBSv1tiquT-Sc-p/view?usp=drivesdk
> > > >
> > > > I then tried from wpa_cli and did not connect. I tried again with a
> > > > wpa_supplicant.conf and also could not connect.
> > > >
> > > > Now I am trying to figure out what I did to allow this connection to a
> > > > sae AP... Now that I have nlmon
> > > > module and iwmon, I will see if I can re-connect, somehow.
> > > > The brcmfmac is such a pain.
> > > > When I get a wpa3/SAE connection, I will make a pcap and post it.
> > > > I actually was able to make one with wpa_supplicant once and actually
> > > > passed data, but it does not seem to work today.
> > > >
> > > > Keith
> >
> > I am back at this. Messed around for a *lot* trying to get it to
> > connect via wpa_cli and connman and was unable to get it to connect. I
> > find both connman and wpa_supplicant so tough to figure out what I am
> > supposed to do to get it to work. I was able to, once, get wpa_cli to
> > connect via wpa3 a while back, but no more. It does not appear that
> > the current git version nor the default version of connman allow an
> > SAE connection on the Pi...
> >
> > Finally, I was able to get it to connect using the current, default
> > RPiOS wpa_supplicant and nmcli on a Pi5. No purpose built packages.
> > just the defaults. Now to see if I can get it to work on the one I
> > built using the later kernel that I built with the nlmon module. If I
> > have luck, I'll post a log.
> >
> > On the hostapd computer:
> > Aug 17 15:36:25 jackson hostapd[2204]: ap0: AP-STA-CONNECTED d8:3a:dd:d2:ae:3c
> > Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c
> > RADIUS: starting accounting session ACB7F795BBC8FF5E
> > Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c WPA:
> > pairwise key handshake completed (RSN)
> > Aug 17 15:36:25 jackson hostapd[2204]: ap0: EAPOL-4WAY-HS-COMPLETED
> > d8:3a:dd:d2:ae:3c
> > Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c
> > RADIUS: starting accounting session ACB7F795BBC8FF5E
> > Aug 17 15:36:25 jackson hostapd[2204]: ap0: STA d8:3a:dd:d2:ae:3c WPA:
> > pairwise key handshake completed (RSN)
> >
> > and on the Pi:
> > Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: Trying to associate
> > with SSID 'deskSAE'
> > Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.4925]
> > device (wlan0): supplicant interface state: scanning -> associating
> > Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.4925]
> > device (p2p-dev-wlan0): supplicant management interface state:
> > scanning -> a>
> > Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: Associated with
> > d8:3a:dd:60:a3:0c
> > Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0:
> > CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
> > Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: WPA: Key negotiation
> > completed with d8:3a:dd:60:a3:0c [PTK=CCMP GTK=CCMP]
> > Aug 17 15:36:25 pi5 wpa_supplicant[669]: wlan0: CTRL-EVENT-CONNECTED -
> > Connection to d8:3a:dd:60:a3:0c completed [id=0 id_str=]
> > Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6431]
> > device (wlan0): supplicant interface state: associating -> completed
> > Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6432]
> > device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure)
> > successfu>
> > Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6433]
> > device (p2p-dev-wlan0): supplicant management interface state:
> > associating ->
> > Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6441]
> > device (wlan0): state change: config -> ip-config (reason 'none',
> > sys-iface->
> > Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6452]
> > dhcp4 (wlan0): activation: beginning transaction (timeout in 45
> > seconds)
> > Aug 17 15:36:25 pi5 avahi-daemon[542]: Registering new address record
> > for fe80::d8bd:98f9:b458:1f79 on wlan0.*.
> > Aug 17 15:36:25 pi5 NetworkManager[2142]: <info>  [1723926985.6629]
> > dhcp4 (wlan0): state changed new lease, address=192.168.5.177
> >
> > root@pi5(rw):~# wpa_supplicant -v
> > wpa_supplicant v2.10
> > Copyright (c) 2003-2022, Jouni Malinen <j@w1.fi> and contributors
> > root@pi5(rw):~# NetworkManager -V
> > 1.42.4
>
> So with that same configuration but on the Pi3B+ running the kernel
> with the proper module, I was able to get a pcap of a connection to an
> wpa3/sae SSID.
> It is attached. So, the current default install on the RPis that run
> the brcmfmac card identified as this:
>
> [    6.473673] brcmfmac: brcmf_fw_alloc_request: using
> brcm/brcmfmac43455-sdio for chip BCM4345/6
> [    6.841681] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
> wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID
> 01-b677b91b
>
> will connect to an SAE authenticated ssid with nmcli and wpa_supplicant
>
> Keith

Also, just noticed this in the log:
Aug 17 18:33:04 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE
Aug 17 18:33:18 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE
Aug 17 18:33:25 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE
Aug 17 18:33:48 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE
Aug 17 18:33:54 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE
Aug 17 18:34:04 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE
Aug 17 18:34:34 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE
Aug 17 18:34:41 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE
Aug 17 18:34:47 pi5 iwd[2089]: SAE unsupported: brcmfmac needs
CMD_EXTERNAL_AUTH for SAE

Any recent wifi certifications with IWD?

[Bryce Johnson]

Hi All,
I was wondering if anyone had recent wifi certification experience.
We are working on a new product that will get certificated in the next
6-12 months.  Last time (about a year ago), we had to switch back to
wpa_supplicant last minute because of one failed test around PMKSA
caching. IMO it was a pretty ambiguous test, but couldn't get the wifi
alliance to let us skip that test.

There was some discussion at the end of this thread:
https://lore.kernel.org/all/504042cf-1704-a590-391c-009b500cf505@gmail.com/T/

We got our testing in last time just before some additional wifi
certification requirements.  So there are probably some stricter tests
now.

If anyone successfully got certification with IWD I'd love to know!

Bryce

Re: Any recent wifi certifications with IWD?

[James Prestwood]

Hi Bryce,

On 8/30/24 9:37 AM, Bryce Johnson wrote:
> Hi All,
> I was wondering if anyone had recent wifi certification experience.
> We are working on a new product that will get certificated in the next
> 6-12 months.  Last time (about a year ago), we had to switch back to
> wpa_supplicant last minute because of one failed test around PMKSA
> caching. IMO it was a pretty ambiguous test, but couldn't get the wifi
> alliance to let us skip that test.
>
> There was some discussion at the end of this thread:
> https://lore.kernel.org/all/504042cf-1704-a590-391c-009b500cf505@gmail.com/T/
>
> We got our testing in last time just before some additional wifi
> certification requirements.  So there are probably some stricter tests
> now.
>
> If anyone successfully got certification with IWD I'd love to know!
>
> Bryce
>
Just to remind me, was the only issue you know of PMKSA support? I'm 
having a really hard time finding any actual requirements on the 
wifi-alliance web page. In that thread you had sent some of the 
requirements, how did you get those?

Thanks,

James

Re: Any recent wifi certifications with IWD?

[Bryce Johnson]

Hi James
At the time that was the only issue.  Although apparently there are
some new requirements now.

Looking back through my emails it was
SAE-5.2.1 test case.  In the end they claimed the Security R3 MRD v1.3
document required it(6.3.1, 'SAE Hash-to-Element).  Honestly it was
about a month of going back and forth and they did not want to explain
much, just saying it was needed

"
Dear member,
Pls read the subject/objective of this test case and you should be
aware of that the feature of PMK cache is necessary.
Btw, this functionality is very basic and useful. I didn’t see any
other vendors not support this feature ever.
"

I can forward you the Security R3 MRD v1.3 document directly
Bryce

On Wed, Sep 4, 2024 at 12:59 PM James Prestwood <prestwoj@gmail.com> wrote:
>
> Hi Bryce,
>
> On 8/30/24 9:37 AM, Bryce Johnson wrote:
> > Hi All,
> > I was wondering if anyone had recent wifi certification experience.
> > We are working on a new product that will get certificated in the next
> > 6-12 months.  Last time (about a year ago), we had to switch back to
> > wpa_supplicant last minute because of one failed test around PMKSA
> > caching. IMO it was a pretty ambiguous test, but couldn't get the wifi
> > alliance to let us skip that test.
> >
> > There was some discussion at the end of this thread:
> > https://lore.kernel.org/all/504042cf-1704-a590-391c-009b500cf505@gmail.com/T/
> >
> > We got our testing in last time just before some additional wifi
> > certification requirements.  So there are probably some stricter tests
> > now.
> >
> > If anyone successfully got certification with IWD I'd love to know!
> >
> > Bryce
> >
> Just to remind me, was the only issue you know of PMKSA support? I'm
> having a really hard time finding any actual requirements on the
> wifi-alliance web page. In that thread you had sent some of the
> requirements, how did you get those?
>
> Thanks,
>
> James
>