First of all, I know rpi3 wifi is cheap, and I know I can’t expect too much…
We use resin-wifi-connect (which works very good!) to setup the wifi connection on our devices.
The problem occurs only when the AP is away from the raspberry… the signal quality isn’t very good, but it works.
Devices are online, and after a couple of hours they become offline.
The problem is that they won’t come online again. until you reboot the raspberry.
At first with only 4 devices installed with 1 customer, we thought it was a particular problem for that customer only…
but now, with more devices installed on other customers, we found that it wasn’t an isolated problem.
I’ve tried restarting the wifi on the raspberry, by running resin-wifi-connect again (with clear=false) but it won’t connect.
A device reboot works perfect, un-plug and re-plug the device from the wall, or a device reboot from resin API works perfect, after the reboot, the wifi works.
Do you have any ideas of what can I do? I do not want to reboot the device 3 times per day to get it connected to wifi.
Thanks!
Edit: this was happening on resin OS 1.X we updated to resin OS 2.X (networkmanager instead of connman) and the problem persists…
Does this happen on 2.X devices without resin-wifi-connect? Have you tried using an external wireless interface?
To be honest I would expect NM to recover from these kinds of issues
But found a workaround that so far it’s giving me good results:
turn off wifi with ifdown
wait a minute
turn it on with ifup
wait another minute
run resin-wifi-connect
The last step is necessary to force NM to reconnect to the wireless network right away.
I think the problem is more like the wireless interface not being able to see the wireless network (since it’s poor signal) that is why NM wont reconnect.
However, I’ve no clue about why restarting the interface works.
Taking a wild shot in the dark here, it sounds like it might be that the device is losing connection and then goes long enough without getting a good signal from the AP that it gives up and resin-wifi-connect kicks in.
When this happens, can you see if the device is broadcasting an AP of its own? If so, that’s probably what is happening.
resin-wifi-connect will not create an AP if it is able to connect to the configured AP, but if it is unable to connect it will clear the credentials and create an AP. The state flow diagram for resin-wifi-connect helps make this clearer than my description
This is why I’m wondering if the device is creating an AP; if so it would be likely that it failed to connect with the cached credentials.
ResinOS 2.0.7 should include an improvement in this area when it is released.
commit c804737aee83be02bd75237623e2f8ed8b9bb82a
Author: Petros Angelatos <petrosagg@gmail.com>
Date: Tue Jun 13 13:09:32 2017 +0300
networkmanager: set reconnection attempts to infinity
NetworkManager will attempt to connect to a network 4 times by default
before bailing out. This is unsuitable for resin device that can be
deployed in flaky networks.
Setting autoconnect-retries-default to 0 will cause NM to never stop
trying to connect.
https://developer.gnome.org/NetworkManager/unstable/nm-settings.html#nm-settings.property.connection.autoconnect-retries
Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
I was getting same problems as you, and then set up the connections in boot partition. Even with the connections set in that folder, and disabling the resin-wifi-connect script from start script, I’m managing to get the same disconnection errors after 5 or 6 hours. What could it be?
EDIT:The problem was on wifi signal from customer. After it normalized, the Network Manager managed (pun intended) to reconnect automatically. The system is now working fine.
I’m seeing a similar issue on Beaglebone Green Wireless devices running ResinOS 2.4.2+rev1. I am not (yet) using resin-wifi-connect. It happened randomly on one device, but we were able to reproduce it:
Eight devices running the same version of ResinOS and application in a room with a wireless access point (Ubiquiti Unifi AP Pro). All had stable connections with good signal strength.
I unplugged the AP, moved it maybe 100ft from it’s original location, and plugged it in there. The devices were untouched.
Five devices reconnected fairly quickly (~10minutes), three devices never reconnected (going on 4 hours at this point).
It feels like the issue only occurs with poor signal strengths, but I’ll try unplugging the AP and re-connecting it in the same room to see what happens.
Unfortunately these devices all have prod images on them at the moment, so I don’t have any serial logs to dig into.
I ran the “unplug and reconnect in the same room” experiment last night, and everything reconnected just fine. So I tried the “unplug and reconnect far away” experiment again, and… everything connected just fine.
It could be a result of better RF conditions (less interference) as nobody else was in the office at that time. As a data point, the devices connected to the distant AP were reporting link quality in the 35 to 37 range, and signal in the -72 to -74db range.
I’ll run the test again today with a crowded office in an attempt to reproduce it again, capture the iwconfig status data, and run Ubiquiti’s RF environment scans to see if I can narrow it down to congestion, dropped packets, etc.
I am experiencing the same problem, our device (RPI3) runs on Resin OS 2.2.0+rev1 (prod). We have quite a bad wifi connection at our clients deployment and the connectivity drops in and out. However for a couple of times the wifi didn’t come back up again and only a hard power cycle of the RPI could get the device to connect again.
I’m suffering from the same issue, RPi denies to reconnect after a while when signal is weak, and only rebooting helps.
I hope autoconnect-retries=0 will work (I didn’t try it yet), but redeploying the whole fleet (~60 devices in different locations) is a really sad story!
Please let us know if you can fix this remotely (I’m pretty sure you can, if you can update resinOS remotely).
