We have been using iwd to manage the wifi for a number of years on our RPi based Audio player installation. iwd is very fast (compared to wpa_supplicant) and very well supported even on our RPis. It works great as a client to connect to ssids and we are very happy with its performance on the RPis.
We have recently set up the Pi to boot, look for an ethernet/wifi connection and failing one, start an AP on the wlan0 to allow a user (AP client) to configure the wireless from this AP connection. What we have found is that when iwd scans for ssids (the brcmfmac claims capability of being in AP mode then performing a station wifi scan) it disconnects any devices connected via AP before anything can be configured...
.
We discovered that when we use wpa_supplicant for this scanning along with hostapd controlling the AP, that it is much more stable and most times, AP clients are not disconnected. It is not perfect, but it is use-able in this format.
I discussed this with the iwd devs and we finally figured out what was going on: iwd was using a 'passive scan' to scan for ssids whereas wpa_supplicant was using an 'active scan'. I am not that versed in kernel driver and iw details as to what this all means, but believe him when he says this as he has made a patch to iwd which remedies this behavior. With the patch applied to make iwd only use active scans, the AP is stable regardless of if iwd is controlling it or if hostapd is controlling it and clients are not disconnected when it scans for ssids
.
The question is: Can the brcmfmac driver be patched to fix this? I have posted to the linux-wireless and linux-brcm80211 lists and there has been no response with anything directly applicable to pointing out that this problem is 'intended behavior' on teh brcmfmac and all others are wrong nor that the brcmfmac driver is wrong but 'won't fix' (though that is my guess at how this will be 'resolved'). Therefore I post here to see if something can shake out.
I have a patch for our player which we are using, so no biggie for me, but if anyone else wants to do this 'ap configuration', which I feel is pretty common these days, this should be fixed such that the brcmfmac driver behaves the same as the intel or other cards I have tried this on. I did not say this, but on the 2 intel cards I have tried this on, the 'unpatched' iwd scans will *not* disconnect all AP clients.
If someone wants a bookworm image I crafted that is minimal and shows this behavior, I can send a link.
Gearhead
We have recently set up the Pi to boot, look for an ethernet/wifi connection and failing one, start an AP on the wlan0 to allow a user (AP client) to configure the wireless from this AP connection. What we have found is that when iwd scans for ssids (the brcmfmac claims capability of being in AP mode then performing a station wifi scan) it disconnects any devices connected via AP before anything can be configured...
.
We discovered that when we use wpa_supplicant for this scanning along with hostapd controlling the AP, that it is much more stable and most times, AP clients are not disconnected. It is not perfect, but it is use-able in this format.
I discussed this with the iwd devs and we finally figured out what was going on: iwd was using a 'passive scan' to scan for ssids whereas wpa_supplicant was using an 'active scan'. I am not that versed in kernel driver and iw details as to what this all means, but believe him when he says this as he has made a patch to iwd which remedies this behavior. With the patch applied to make iwd only use active scans, the AP is stable regardless of if iwd is controlling it or if hostapd is controlling it and clients are not disconnected when it scans for ssids
.
The question is: Can the brcmfmac driver be patched to fix this? I have posted to the linux-wireless and linux-brcm80211 lists and there has been no response with anything directly applicable to pointing out that this problem is 'intended behavior' on teh brcmfmac and all others are wrong nor that the brcmfmac driver is wrong but 'won't fix' (though that is my guess at how this will be 'resolved'). Therefore I post here to see if something can shake out.
I have a patch for our player which we are using, so no biggie for me, but if anyone else wants to do this 'ap configuration', which I feel is pretty common these days, this should be fixed such that the brcmfmac driver behaves the same as the intel or other cards I have tried this on. I did not say this, but on the 2 intel cards I have tried this on, the 'unpatched' iwd scans will *not* disconnect all AP clients.
If someone wants a bookworm image I crafted that is minimal and shows this behavior, I can send a link.
Gearhead
Statistics: Posted by gearhead — Thu Feb 22, 2024 2:03 pm