wifi-connect
wifi-connect copied to clipboard
Scan only shows 1 ssid some of the time
Running on a raspi3 B v1.2 on Buster. Not using wpa.
Sometimes scan will only return one ssid, even if all of the available networks show up in iwlist just before launching.
We ARE setting a network priority on the ssid that always shows up, but otherwise running according to the README.
I get this also.
That's interesting. What happens if you run nmcli d wifi rescan
just before running wifi-connect
? iwlist
uses the older wireless extensions for Linux where NetworkManager is talking to the kernel through the newer netlink mechanism (the iw
utility uses that as well). iw dev wlan0 scan
is also an interesting output.
I will test this out and let you know.
We get the same single network from nmcli d wifi rescan
that we see in wifi-connect.
Interestingly, running sudo iw wlan0 scan
will kick something into gear and then nmcli and wifi-connect will see all available networks. BUT, then, connecting to the network will fail and restart the AP. Then, wifi-connect will show the network we attempted to connect to, allow us to select it, enter credentials, and connect as normal. I have sudo journalctl -fu NetworkManager
output I can sanitize and share if that would be helpful.
Thanks for the feedback! The logs from NetworkManager would not reveal anything most probably, but I could be wrong.
There may be some kernel errors. Recently I have seen more and more instabilities with the RPi WiFi driver/firmware. Could you please also check the dmesg
output and let me know if you see any crashes there.
NetworkManager delegates currently scanning to the wpa_supplicant. In the future probably that will be done by default by iwd - a new wireless daemon from Intel, which has a much cleaner codebase, better automated testing and is using more kernel routines. This one unfortunately is not compatible with the current RPi 4.19 kernel, so switching to it is not an option. The current combination of buggy drivers/firmware and wpa_supplicant issues makes things quite unstable. Other WiFi chips are even worse.
It would be best if I can reproduce this issue and I am going to do a round of testing. Are there any particular steps that you would recommend? You are probably running latest Raspbian Lite (Buster) - correct me if I am wrong. The error should also be affecting our balenaOS since we are running the same kernel and drivers (although patch versions may vary).
Also if you are running Raspbian Lite, are you running it with full system upgrade or a stock one from September?
Running on Raspbian Buster, not Lite. We did a full system upgrade.
Other than avoiding Android 9 (we were having issues with the captive portal that are Android's problem, not yours) nothing specific that I can tell, though let me know if I can provide more detail. Will get the dmesg output in the morning.
No luck with reproducing on my side. I did a full system upgrade and tried this multiple times with power cycling or just rerunning, but the result was the same.
Ok, np. What if you are already connected to a wifi network when you run wifi-connect? (Yes, I understand this is odd.)
@baileysage Actually now that you said this can you run both nmcli d wifi rescan
and nmcli d wifi
before launching WiFi Connect. I believe this should make the problem disappear for you - a workaround of some sort.
Yes I will try this in the next hour or so
On Thu., Jan. 23, 2020, 12:51 Zahari Petkov, [email protected] wrote:
@baileysage https://github.com/baileysage Actually now that you said this can you run both nmcli d wifi rescan and nmcli d wifi before launching WiFi Connect. I believe this should make the problem disappear for you - a workaround of some sort.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/balena-io/wifi-connect/issues/327?email_source=notifications&email_token=AAE7CZBRQBEHPSBDBUBXUXTQ7HKLTA5CNFSM4KG3CGH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJYHCSI#issuecomment-577794377, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE7CZBIIHYVQF6DWFLE4PTQ7HKLTANCNFSM4KG3CGHQ .
@majorz That seems to work! I'll have it tested on a couple different units and let you know if it goes differently.
Awesome, let's keep this open as I would like to add this to wifi-connect itself whenever we upgrade our base library to libnm-rs (the new Rust bindings for libnm).
FYI this is a problem for us when using:
- RPi 4
- balenaOS 2.53.12+rev1
- wifi-connect release v4.3.1
Also still experiencing this issue and it's a real bummer. Requires a hard reboot to resolve. Hoping this fix can be coded into the launch of the app.
Also still experiencing this issue and it's a real bummer. Requires a hard reboot to resolve. Hoping this fix can be coded into the launch of the app.
Although that said, it doesn't seem to be making any difference on a Raspberry Pi 4. Still end up not being able to see any wifi hotpots more often than not.
Also still experiencing this issue and it's a real bummer. Requires a hard reboot to resolve. Hoping this fix can be coded into the launch of the app.
Although that said, it doesn't seem to be making any difference on a Raspberry Pi 4. Still end up not being able to see any wifi hotpots more often than not.
Quick update. Still no success with nmcli d wifi rescan
and nmcli d wifi
. Seems to be some success with iw wlan0 scan
though, being run before Wi-Fi connect launches. Too soon to say for sure if it is a 100% fix, but so far I have not experienced the issue since using it. It is also a smaller install than NetworkManager package which is advantageous.
If you are still experiencing this issue can you try this branch instead and report back on whether it helps: https://github.com/balena-os/wifi-connect/pull/450