From: James Prestwood <prestwoj@gmail.com>
To: Martin Petzold <martin.petzold@tavla.de>
Cc: iwd@lists.linux.dev, Denis Kenzior <denkenz@gmail.com>,
Arend van Spriel <arend.vanspriel@broadcom.com>
Subject: Re: IWD 1.27 with brcmfmac not working for roaming
Date: Wed, 23 Oct 2024 08:28:36 -0700 [thread overview]
Message-ID: <60e609c8-7c83-4510-9a3b-706698705e1b@gmail.com> (raw)
In-Reply-To: <713f032a-a286-47f2-9729-5430e4675b59@tavla.de>
Hi Martin,
On 10/23/24 8:22 AM, Martin Petzold wrote:
> Hi James,
>
> Am 23.10.24 um 15:22 schrieb James Prestwood:
>> Hi Martin,
>>
>> On 10/23/24 5:19 AM, Martin Petzold wrote:
>>> Hi James,
>>>
>>> Am 23.10.24 um 14:13 schrieb James Prestwood:
>>>> Hi Martin,
>>>>
>>>> On 10/23/24 5:02 AM, Martin Petzold wrote:
>>>>> Hi Arend and James,
>>>>>
>>>>> Am 21.10.24 um 20:26 schrieb Arend van Spriel:
>>>>>> On 10/21/2024 7:40 PM, Denis Kenzior wrote:
>>>>>>> Hi Arend,
>>>>>>>
>>>>>>>>
>>>>>>>> I have not seen patches for OWE in brcmfmac. Looking at the
>>>>>>>> supported ciphers:
>>>>>>>
>>>>>>> OWE is an AKM. It still uses CCMP/CMAC underneath.
>>>>>>
>>>>>> My bad. Always confused by those concepts.
>>>>>>
>>>>>>>>
>>>>>>>> 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)
>>>>>>>>
>>>>>>>> The error message seems to match with the above.
>>>>>>>
>>>>>>> I've never seen support for OWE in brcmfmac mentioned. OWE
>>>>>>> requires CMD_AUTHENTICATE / CMD_ASSOCIATE (or CMD_EXTERNAL_AUTH)
>>>>>>> to derive the PMK, so iwd can't support it on FullMAC.
>>>>>>
>>>>>> I have never seen any mention of OWE either. Regarding
>>>>>> CMD_EXTERNAL_AUTH support I recently posted patches on
>>>>>> linux-wireless list as RFT. There has been zero feedback and so I
>>>>>> assume also zero interest. In order to use CMD_EXTERNAL_AUTH the
>>>>>> firmware needs to advertise "sae_ext" in fwcap debugfs file. So
>>>>>> if Martin can check that, ie:
>>>>>>
>>>>>> $ grep sae_ext /sys/kernel/debug/ieee80211/phy0/fwcap
>>>>>>
>>>>>>
>>>>> @James: Could please check the logs (PATCH WAS APPLIED):
>>>>>
>>>>> A. Initial boot and connect (device remained connected)
>>>>
>>>> On this run I'm seeing an agent connecting and issuing an explicit
>>>> connect call rather than IWD autoconnecting. This is fine, and will
>>>> create a new .open profile.
>>>>
>>>> Okt 23 12:39:35 tavla iwd[383]: src/agent.c:agent_free() agent free
>>>> 0xaaaadbf376a0
>>>> Okt 23 12:39:35 tavla iwd[383]: src/agent.c:agent_register() agent
>>>> register called
>>>> Okt 23 12:39:35 tavla iwd[383]: src/agent.c:agent_register() agent
>>>> :1.69 path /agent/1420
>>>> Okt 23 12:39:35 tavla iwd[383]: src/network.c:network_connect()
>>>>
>>>>> B. Reboot -> device does NOT connect
>>>>
>>>> This tells me you have no profile in /var/lib/iwd
>>>>
>>>>>
>>>>> -----
>>>>>
>>>>> tavla@tavla:~$ sudo ls -l /system/var/lib/iwd/
>>>>> insgesamt 4
>>>>> -rw------- 1 root root 0 23. Okt 12:39 XYZ-Gast.open
>>>>> drwx------ 2 root root 4096 4. Apr 2024 hotspot
>>>>> tavla@tavla:~$ sudo cat /system/var/lib/iwd/XYZ-Gast.open
>>>>> tavla@tavla:~$
>>>>
>>>> IWD is looking in /var/lib/iwd as seen by:
>>>>
>>>> Okt 23 12:35:58 tavla iwd[383]: src/storage.c:storage_create_dirs()
>>>> Using state directory /var/lib/iwd
>>>>
>>>> Not sure if you have /system/var/lib/iwd mounted there or what, but
>>>> it seems IWD cannot find that profile. IWD will not autoconnect to
>>>> a random open network without a profile. On your first boot you are
>>>> forcing a connection which should generate a profile, but on the
>>>> second boot no profile exists. So that is where I could check,
>>>> where is the profile going? can you "ls" that directory on the
>>>> _second_ boot to see if it exists?
>>> -----
>>> tavla@tavla:~$ sudo ls -l /var/lib/iwd/
>>> insgesamt 4
>>> -rw------- 1 root root 0 23. Okt 12:39 XYZ-Gast.open
>>> drwx------ 2 root root 4096 4. Apr 2024 hotspot
>>> tavla@tavla:~$ sudo ls -l /system/var/lib/iwd/
>>> insgesamt 4
>>> -rw------- 1 root root 0 23. Okt 12:39 XYZ-Gast.open
>>> drwx------ 2 root root 4096 4. Apr 2024 hotspot
>>> tavla@tavla:~$ sudo cat /system/var/lib/iwd/XYZ-Gast.open
>>> tavla@tavla:~$
>>> tavla@tavla:~$
>>> tavla@tavla:~$ iwctl known-networks list
>>> Known Networks
>>> --------------------------------------------------------------------------------
>>>
>>> Name Security Hidden Last connected
>>> --------------------------------------------------------------------------------
>>>
>>> XYZ-Gast open Oct 23, 11:39 AM
>>>
>>> tavla@tavla:~$ iwctl known-networks XYZ-Gast show
>>> Known Network: XYZ-Gast
>>> --------------------------------------------------------------------------------
>>>
>>> Settable Property Value
>>> --------------------------------------------------------------------------------
>>>
>>> Name XYZ-Gast
>>> Hidden
>>> * AutoConnect yes
>>>
>>> tavla@tavla:~$
>>> tavla@tavla:~$ iwctl station wlan0 show
>>> Station: wlan0
>>> --------------------------------------------------------------------------------
>>>
>>> Settable Property Value
>>> --------------------------------------------------------------------------------
>>>
>>> Scanning no
>>> State disconnected
>>>
>>> -----
>> I was barking up the wrong tree. I found a bug in the BSS selection
>> specific to OWE transitional networks. I just sent an RFC patch to
>> the list. Note, you will still need the earlier patches to disable
>> OWE in order to force the connection to the open network.
>
> Device connected after image upgrade (pre-existing configured network)
> and then also connected after consecutive reboots. I have also tested
> to forget the network, re-configure the network and then do some
> reboots. I also tested manual disconnect and connect. Also tested
> manual disconnect and waiting for auto-connect. Here I can't force any
> roaming (not a mobile device). As I am not 100% confident, I will run
> several more tests also in other environments.
>
> Do you need logs?
No, not if its working. I was able to reproduce the same situation in a
simulated environment so I'm pretty confident the bug is fixed with
respect to OWE/open networks.
>
> However, I still also have some issues with devices in a non-OWE
> network. I am not really confident general connection and roaming is
> behaving as it should. I have seen one disappearing today (no network
> logs available), however that one did not have any of the three
> patches. But this network is using WPA2-PSK with a single router as
> far as I know. Does your last patch only target WPA3 and/or OWE
> environments or also others?
The patches should only change behavior on OWE networks. As far as
roaming that is again up to brcmfmac. IWD just gets notified when a roam
occurred. With OWE disabled though I would expect roaming within open
networks to work as well as with WPA2 as this is quite basic, but I
can't really assume anything here. We would need to see logs if there
was some issue here to know if it was brcmfmac or IWD not acting properly.
>
> I will upgrade all our devices in testing environments and then will
> have to observe carefully...
>
> Nevertheless, thanks for your response and effort!
No worries, glad we at least got the OWE part hopefully figured out.
>
> Martin
>
next prev parent reply other threads:[~2024-10-23 15:28 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 9:43 IWD 1.27 with brcmfmac not working for roaming Martin Petzold
2024-10-09 16:07 ` Denis Kenzior
2024-10-09 16:50 ` Arend Van Spriel
2024-10-09 17:54 ` Martin Petzold
2024-10-10 8:06 ` Martin Petzold
2024-10-12 11:06 ` Martin Petzold
2024-10-12 11:51 ` Arend van Spriel
2024-10-13 15:43 ` Martin Petzold
2024-10-30 19:19 ` Martin Petzold
2024-10-30 19:23 ` James Prestwood
2024-10-09 16:58 ` Arend Van Spriel
2024-10-10 13:20 ` Martin Petzold
2024-10-10 13:36 ` James Prestwood
2024-10-10 13:47 ` Martin Petzold
2024-10-10 13:55 ` James Prestwood
2024-10-11 8:35 ` Martin Petzold
2024-10-11 10:46 ` Martin Petzold
2024-10-12 10:59 ` Martin Petzold
2024-10-15 14:43 ` Martin Petzold
2024-10-15 15:17 ` Denis Kenzior
2024-10-15 19:13 ` Arend van Spriel
2024-10-16 2:04 ` Denis Kenzior
2024-10-16 8:32 ` Arend van Spriel
2024-10-17 10:58 ` Martin Petzold
2024-10-19 14:04 ` Martin Petzold
2024-10-19 14:41 ` Denis Kenzior
2024-10-21 13:34 ` Martin Petzold
2024-10-21 14:40 ` Arend Van Spriel
2024-10-21 14:53 ` Martin Petzold
2024-10-21 15:23 ` James Prestwood
2024-10-21 17:08 ` Arend Van Spriel
2024-10-21 17:20 ` Martin Petzold
2024-10-21 17:40 ` Denis Kenzior
2024-10-21 18:26 ` Arend van Spriel
2024-10-21 18:45 ` Martin Petzold
2024-10-21 18:48 ` Martin Petzold
2024-10-21 18:55 ` Denis Kenzior
2024-10-21 19:08 ` Jeremy Blum
2024-10-22 15:26 ` Denis Kenzior
2024-10-22 16:38 ` Jeremy Blum
2024-10-21 19:15 ` Martin Petzold
2024-10-21 19:11 ` James Prestwood
2024-10-21 20:23 ` Martin Petzold
2024-10-22 6:08 ` Arend Van Spriel
2024-10-21 22:01 ` KeithG
2024-10-21 22:10 ` Martin Petzold
2024-10-22 17:40 ` James Prestwood
2024-10-22 18:04 ` Martin Petzold
2024-10-22 18:21 ` Martin Petzold
2024-10-22 18:24 ` James Prestwood
2024-10-22 18:32 ` Martin Petzold
2024-10-22 18:44 ` Denis Kenzior
2024-10-22 18:47 ` Martin Petzold
2024-10-22 19:10 ` James Prestwood
2024-10-22 18:47 ` James Prestwood
2024-10-22 18:49 ` Martin Petzold
2024-10-22 18:52 ` Denis Kenzior
2024-10-23 12:02 ` Martin Petzold
2024-10-23 12:13 ` James Prestwood
2024-10-23 12:19 ` Martin Petzold
2024-10-23 13:22 ` James Prestwood
2024-10-23 13:34 ` Martin Petzold
2024-10-23 15:22 ` Martin Petzold
2024-10-23 15:27 ` Martin Petzold
2024-10-23 15:30 ` James Prestwood
2024-10-23 15:37 ` Martin Petzold
2024-10-23 15:28 ` James Prestwood [this message]
2024-10-23 15:11 ` Arend Van Spriel
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=60e609c8-7c83-4510-9a3b-706698705e1b@gmail.com \
--to=prestwoj@gmail.com \
--cc=arend.vanspriel@broadcom.com \
--cc=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=martin.petzold@tavla.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.