Re: IWD 1.27 with brcmfmac not working for roaming

[James Prestwood <prestwoj@gmail.com>]

On 10/23/24 8:27 AM, Martin Petzold wrote:
> Am 23.10.24 um 17:22 schrieb Martin Petzold:
>
>> 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.
> btw. it did NOT auto re-connect if I disconnected manually (state 
> "degraded" in networkctl). I assume this is correct, if it was forced 
> to disconnect.
I'm not familiar with networkctl specifically, but if you issue a 
Disconnect DBus call to IWD that disables autoconnect until you manually 
connect again.