Re: Connection loss (IWD HEAD with latest OWE / BSS selection patches) - brcmfmac driver

Martin Petzold
2024-10-26T10:01:07Z

Hi James,

Am 26.10.24 um 00:22 schrieb Martin Petzold:
> Hi all,
>
> Am 25.10.24 um 17:17 schrieb James Prestwood:
>>> [...]
>>> I'm quite sure this is related to your BSS / AKM patch. It happened
>>> on a client here after an image upgrade to this version. I have
>>> never seen this before.
>> For WPA2 those patches _should_ have zero effect. Based on your logs
>> the behavior here is entirely different than with OWE. Before the
>> connection to the OWE network was actually failing (failed within
>> brcmfmac). Here IWD tried to connect and got no event back from the
>> driver. To know this without a doubt we would need to to run iwmon
>> and see the communication between IWD and the kernel.
>>>
>>> Also, I have debugging for BRCM enabled (CONFIG_BRCMDBG=y and
>>> CONFIG_DEBUG_FS=y). It sounds strange if there is no output, even
>>> not before.
>>
>> Maybe Arend has some idea of why userspace could send a CMD_CONNECT
>> and get no associated CMD_CONNECT event?
>>
>> The fact that even manually connecting didn't work after this
>> happened tells me the driver is "stuck". Did you try cycling the
>> driver with modprobe?
>
> There may have been a problem on my side, sorry. I will come back, if
> I see this again.

I found a bug on our side, which results in too many IWD agent requests
if the networks constantly goes down and up again. It seems then at some
point in time this leads to a deadlock of the network (what we have
seen). However, I fixed this and still I have some devices constantly
going away and coming back (currently only in the OWE Transition network).

I would like to ask you some questions in order to maybe narrow down the
problem:

1. I have systemd-networkd configured for the Ethernet interface
(however, our devices don't have a network cable connected!) + IWD with
EnableNetworkConfiguration=true. Could this be in conflict?

-----

[Match]
Name=eth0

[Network]
DHCP=ipv4

[Link]
RequiredForOnline=no

-----

[General]
EnableNetworkConfiguration=true

[Network]
NameResolvingService=systemd
EnableIPv6=false

[DriverQuirks]
OweDisable=brcmfmac

-----

2. I have systemd-resolved enabled (Debian bookworm package should
create the link / stub) and set in IWD configuration
(NameResolvingService=systemd). Anything else to do?

3. Could it be a problem that I poll the state from iwctl every 10
seconds? (yes, I will switch to dbus, once I find some time for that!)

4. I disabled IPv6 in IWD (EnableIPv6=false) because I first was trying
IWD 1.x before and there it was disabled by default (and I wanted to
rule out problems from IPv6). networkd Ethernet interface is configure
with DHCP=ipv4.

5. As I wrote in 4., networkd is configured with DHCP=ipv4. Could there
be some DHCP conflict between IWD and networkd?

Also, I will write another message to the list calling for the IWD team
and Broadcom to better support the BCM chips. My SOM vendor Variscite is
world leading and they use NetworkManager with BCM4339 without any
problem in their BSP / SDK (as they say, and of course I am just before
switching back to that).

This means for me there is some problem with IWD and of course
integration of IWD and brcmfmac. However, this will never work, if IWD
does not have BCM devices in their tests and Broadcom / Cypress does not
have IWD in their tests. IWD is openly declared as the successor of
wpa_supplicant, and also promotet in Debian documentation starting from
11. I know that Intel is a good sponsor of IWD, I hope that Broadcom /
Cypress don't fall into a a trap, when IWD always works like a charm
with Intel chips and produces only headaches (and in my case potentially
million loss) when using BCM chips. As I find on the list and elsewhere,
there are a lot of problems. On the other side, it is the "job" of the
IWD team of course - maybe Broadcom / Cypress should step in in order to
remain world leader?!

Thanks,

Martin