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