Re: brcmfmac disconnects when iwd scans

Arend Van Spriel <[email protected]> Fri, 09 May 2025 18:59:50 +0200
Newsgroups dev.linux.lists.iwd
Message-ID <[email protected]>
On May 9, 2025 4:46:14 PM KeithG <[email protected]> wrote:

> On Wed, May 7, 2025 at 6:02 PM KeithG <[email protected]> wrote:
>>
>> On Wed, May 7, 2025 at 2:44 PM KeithG <[email protected]> wrote:
>>>
>>> On Wed, May 7, 2025 at 9:27 AM Arend van Spriel
>>> <[email protected]> wrote:
>>>>
>>>> On 5/7/2025 3:54 PM, KeithG wrote:
>>>>> further information...
>>>>>
>>>>> I tried this with 2 different pi4s and have been able to confirm
>>>>> wpa_supplicant/hostapd is stable on the Pi4 (will try others when I
>>>>> get a chance). I also tried both the 'shipping' brcmfmac43455 firmware
>>>>> and the 'latest'. It is only with the 'latest' that I get reliable
>>>>> connections. With the 'shipping' version, I can get connections for
>>>>> both wlan0 with wpa_suppolicant and ap0 with hostapd, but the ap0
>>>>> connection is flaky without any connection on wlan0. And I cannot
>>>>> sustain both connections at all. This 'latest' firmware is required
>>>>> for a sustainable, reliable ap0 with connection with hostapd.
>>>>>
>>>>> this is the firmware required:
>>>>> [    3.658201] brcmfmac: brcmf_fw_alloc_request: using
>>>>> brcm/brcmfmac43455-sdio for chip BCM4345/6
>>>>> [    3.660643] usbcore: registered new interface driver brcmfmac
>>>>> [    4.041524] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob
>>>>> available (err=-2)
>>>>> [    4.042269] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6
>>>>> wl0: Oct 28 2024 23:27:00 version 7.45.286 (be70ab3 CY) FWID
>>>>> 01-95efe7fa
>>>>>
>>>>> The only annoyance I get is that the log fills up with failed scan messages:
>>>>> May 07 08:43:11 deskrune wpa_supplicant[604]: wlan0: Failed to
>>>>> initiate sched scan
>>>>
>>>> The scheduled scan is basically a scan offload in which user-space tells
>>>> the driver what to look for and how often (hence scheduled). The
>>>> advantage of the scheduled scan is that the host (RPi) goes to sleep
>>>> while the wifi chip is on the lookout for the ssid. No idea why it is
>>>> failing though.
>>>>
>>>>> the Pi still works and is scanning because when a known ssid appears,
>>>>> it immediately connects, so it is scanning, I just get this message.
>>>>
>>>> What I recall from wpa_supplicant behavior is that it does a regular
>>>> scan for a configured ssid and after a number of attempts it does try to
>>>> setup a scheduled scan if the driver supports it. When it fails it
>>>> simply continues with the regular scans. The brcmfmac driver supports
>>>> scheduled scan so it seems like regression although apart from the log
>>>> message the end-user is not really affected. I expect it will not make
>>>> much noticable difference on the energy bill. ;-)
>>>>
>>>>> Now that I have this working well with wpa_supplicant and know how to
>>>>> get it all 'up' and stable, I will start investigating what
>>>>> differences there are with iwd and why it is flaky. Please guide me as
>>>>> to the best way to do this.
>>>>
>>>> Were you successful using nlmon. I suspect differences should show up
>>>> between wpa_supplicant and iwd.
>>>>
>>>> Regards,
>>>> Arend
>>>
>>> I will use nlmon and see what the difference is. Will post them when I get 
>>> them.
>>>
>>> Keith
>>
>> This is an iwmon log showing the hostapd up then a connection from my
>> laptop then a wpa_supplicant connection to my phone acting as a hot
>> spot.
>>
>> https://drive.google.com/file/d/12NhxYT-gF0K2NrBfYEpSvcuGQ6UyejQD/view?usp=sharing
>>
>> This is an iwmon log showing the same activities, but with iwd
>> managing the ap. The laptop connecting, then connecting to the phone
>> as a hot spot. Both disconnected. and passed no data.
>>
>> https://drive.google.com/file/d/1diSp32FXpHjLzQeC5gF-tlNNHji8a1l5/view?usp=sharing
>>
>> I do not know how to read these, but hopefully they will provide some guidance.
>>
>> Keith
>
> Playing with this setup a bit more. It seems that my setup of creating
> ap0 and running hostapd on it and setting up wpa_supplicant@wlan0 to
> run the wlan0 and using wpa_cli is more solid than it has even been. I
> can have both interfaces active for a while. I am connected to the RPi
> via ap0 from a laptop and wlan0 is connected to my phone as a hotspot
> and both interfaces stay up and are functional and pass data, at least
> initially. This stability is only apparent with the latest firmware,
> though. As long as there is no connection on wlan0 (regardless of
> wpa_supplicant scanning), the ap0 connection stays connected.
> Firmware: BCM4345/6 wl0: Oct 28 2024 23:27:00 version 7.45.286
> (be70ab3 CY) FWID 01-95efe7fa
> With the shipping firmware (265), the interface is flaky and ap0 will
> go down almost immedaitely after connecting and I am unable to
> maintain both at the same time.
>
> With this setup, things work really well and the only strange thing I
> am getting is a 'failed scheduled scan' message in the log every ~6
> sec.
>
> May 09 08:53:50 pi4 wpa_supplicant[2254218]: wlan0: Failed to initiate
> sched scan
> May 09 08:53:57 pi4 wpa_supplicant[2254218]: wlan0: Failed to initiate
> sched scan
> May 09 08:54:03 pi4 wpa_supplicant[2254218]: wlan0: Failed to initiate
> sched scan
> May 09 08:54:09 pi4 wpa_supplicant[2254218]: wlan0: Failed to initiate
> sched scan
> May 09 08:54:16 pi4 wpa_supplicant[2254218]: wlan0: Failed to initiate
> sched scan
> May 09 08:54:22 pi4 wpa_supplicant[2254218]: wlan0: Failed to initiate
> sched scan

I thought wpa_supplicant had a config option to disable scheduled scan, but 
can not find it. You can disable it in brcmfmac using feature_disable=2 
modparam.

Regards,
Arend