New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
list of detected wifi access points is empty #206
Comments
I'm happy to provide more details as I can connect to the rpi through the wifi-connect access point, so if think some other logs might be helpful to investigate this issue, please tell me. Also do you know a temporary workaround that I can run to force network manager to reconnect to my initial wifi access point, so that I don't need to hard reboot the device? |
Hi, I will check the logs now and let you know if I find anything. |
The wifi-connect logs definitely reveal an issue: it should not start the access point when no SSIDs are available. The empty SSIDs list is another issue that we need to look into. I am thinking about elevating the log level of NetworkManager and wpa_supplicant, and running some diagnostic code that we can try a few things with it. I will do some research tomorrow on this and let you know how that goes. I had a non-related to WiFi Connect report about RPi 3 and NetworkManager not reporting any networks, so I am definitely interested in figuring out how to workaround this issue without reboots or driver reloads. |
Ok, thanks |
@bbinet I started implementing this here: https://github.com/resin-io-playground/networkmanager-empty-ssids It elevates the log levels of NetworkManager and wpa_supplicant, and then starts to check whether the SSID list is empty each 30 seconds. If the list is empty it triggers a rescan and waits 10 seconds to check whether they are available. I am going to do local tests with it tomorrow and hopefully I will be able to reproduce an empty list. I am thinking to try it using a router and also a hotspot on my phone. If I am not able to reproduce, I may ask you to run the script on a device that has this issue. But let's see first what will happen with the local testing. I will keep you posted. |
Sure, I'm also running your |
I was able to reproduce zero access points available locally. The RequestScan method brought back the access point list, which is good news. I will check the logs now and do more testing. |
I've also been able to reproduce the issue. Here are the logs of the ssids.py script: Here are the logs of NetworkManager service: Here are the logs of the container that runs wifi-connect: |
@bbinet that is really useful! In your case the RequestScan call did not bring back the list with SSIDs, which is more like the actual problem, than what I was able to reproduce here. I still have not got to chance to check the NM logs you attached for the specifics, but I will do that first thing tomorrow and will follow up with you. Thanks again! |
@bbinet I did different can on the instrumentation script: if the RequestScan does not work, it now tells NM to unmanage and then manage the device again. If that does not work, it then restarts the NM service. I also added timestamped logging. Can you please run this again, but this time do not start WiFi Connect together with the script (assuming that the connection profile is defined)? Also you may reboot the device after the application update, so that we get only fresher logs. If you reproduce something, please attach the logs of wpa_supplicant as well. Thanks! |
@majorz but if I don't run WiFi Connect together with the script, I won't be able to log in to get the logs... |
Actually now on second thought, you may leave it running, it should not be a problem. |
@majorz Let's run it |
@bbinet one thing I forgot to mention is that I changed the implementation to use libnm as a higher level alternative to using dbus directly, so the Dockerfile has changed. |
@bbinet I found an issue with this version and applied a fix. Can you please run the latest version instead? I also made the project to use docker-compose for easier local testing, but the old structure is preserved in the ssids directory. |
|
(I've installed python3-gi, but it may not be sufficient?) |
It will need libnm-dev as well for this to work. I am using a Debian Buster base image, so that it is more recent and compatible with the one running on the host OS. |
@majorz the new ssids.py script is now running (still on debian jessie image though). I hope I'll be able to reproduce the issue this afternoon, as I'm leaving tonight for 5 days off. |
Sorry, I meant Debian Stretch (not jessie) |
Thanks! I think it should be fine. I am running it locally as well, but not sure whether I will be able to reproduce. I will run it on a few other devices as well later on. Good luck! |
I made some adjustments on the diagnostic script, as there is a caching bug with python-gir, which led to incorrect reporting of access point count. |
I'm back at work today, so I've updated the ssids.py script, but I have some encoding issues:
|
It seems to be fixed if I set the env variable: PYTHONIOENCODING=utf-8 |
In my testing here with RPi 3 I also reproduced multiple times a scenario where 0 access points were reported by NetworkManager. However NM detected this and triggered a RequestScan which brought back the list with access points. I will test today with a RPi 1, since I do not have a zero w, but it has the same wifi chip, so let's see what happens. |
I got confused, the RPi 1 does not have a built-in wireless chip. RPi 3 B has the same wireless chip as Zero W. |
@majorz my rpi zero w is currently running ssids.py and I'll drop you a message as soon as I've reproduced the issue. |
Fingers crossed! |
I am thinking about the following modifications in WiFi Connect:
|
@majorz this sounds good. Also, I was able to reproduce the issue this night, but sadly I had used I will restart completely my rpi, and run ssids.py script again... Here are the logs of the ssids.py script: Here are the logs of NetworkManager service: Here are the logs of wpa_supplicant service: Here are the logs of the container that runs wifi-connect: |
Ooops, I left a |
@bbinet Done! Please run the new version as the previous one did not attempt to unmanaged the device or restart NM. I also added PYTHONIOENCODING in the Dockerfile. And also something in the compose since wifi-connect's dnsmasq needs it (although the last one should not have affected you). |
@majorz Thanks, I've just restarted my rpi with the new ssids.py script. Let's wait for the issue to show up again. |
Sorry I was not able to reproduce the issue for 10 days... |
@bbinet alright, I will include the changes we talked above with invoking RequestScan on start and also restarting NetworkManager once if access points are not available. |
@majorz ok. |
@majorz Any news on this issue? I'm still getting empty list of wifi access points from time to time: if I manually restart NetworkManager from the hostos then it works again. |
No much progress on this issue yet. I am planning to address it till the end of the month. |
Ok, thank you @majorz |
I'm still facing this issue from time to time: this is quite painful as we cannot connect to the device until the next reboot (though we have configured a force reboot every night to workaround this issue). |
There is a new I am going to work on this once we release this bigger update, since I would like to depend on the new library for the scanning notification mechanisms. Also we are going to integrate WiFi Connect in Resin OS itself. We are figuring the exact details currently. |
Ok, thanks for the update, and for your efforts in this project. |
I'm still seeing this issue, any idea for a fix? |
@andrewjaykeller I left you a comment in the other thread here (about the same issue): #232 (comment) |
If you are still experiencing this issue can you try this branch instead and report back on whether it helps: #450 |
We often have the following case: when the rpi starts, it correctly connects to the wifi access point (that was previously configured using wifi-connect captive portal), but after a few minutes or a few hours, the wifi-connect is starting (probably because the connection was temporarily lost), and the captive portal shows an empty list of detected wifis.
But we have a lot of wifi access points around, so there must be an issue here as the list should not be empty...
The rpi never connects back to our initial wifi access point, until we manually reboot the device.
Here is my start.sh script:
Here are the logs of NetworkManager service:
https://gist.github.com/bbinet/d0ed2e5465824ef2594589b383cc5f93#file-networkmanager-log
Here are the logs of the container that runs wifi-connect:
https://gist.github.com/bbinet/d0ed2e5465824ef2594589b383cc5f93#file-wifi-connect-log
Front conversations
The text was updated successfully, but these errors were encountered: