Re: brcmfmac disconnects when iwd scans
KeithG <[email protected]> Fri, 9 May 2025 09:46:01 -0500
| Newsgroups | dev.linux.lists.iwd |
|---|---|
| Message-ID | <CAG17S_PxYNxLpAMzXOuS6riv46G22zpOM0rT0D7Xp-usbWyo+A@mail.gmail.com> |
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 have only the wpa_supplicant-wlan0.conf in /etc/wpa_supplicant and have removed the /etc/network directory (no other configs or scripts). I use wpa_cli to select and manage ssids. iwd cannot perform this feat as the ap0 goes down before a connection can be made (most times). The flakiness appears to be related to iwd scanning on wlan0 Keith