Raspberry pi 3 Wifi issues on poor signal

Hi guys!

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.


Edit: this was happening on resin OS 1.X we updated to resin OS 2.X (networkmanager instead of connman) and the problem persists…

1 Like


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 :confused:

Hi Joe,

Yes I thought the same thing :confused:

Haven’t tried without resin-wifi-connect.

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.

I think resin-wifi-connect wont raise the AP up if the credentials are already set… I am correct?

to reconnect I always use clear=false in resin-wifi-connect.

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 :slight_smile:

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.

I see what you mean, but the retry flag is set to false:

Anyways, I have setup the connection files under the boot partition, in system-connections

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.

    Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
1 Like

That sounds very promising!

I will do some tests when it’s available and report back here.

Hi @diegosucaria,

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.

Just yesterday it happened again on a Dev decide I have in my desk.

After a general power loss, the raspberry turned on faster than the wireless AP, so it didn’t connect at boot up.

It never connected, after hours waiting I had to power cycle the rpi.


What version of ResinOS are you using?

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:

  1. 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.
  2. I unplugged the AP, moved it maybe 100ft from it’s original location, and plugged it in there. The devices were untouched.
  3. 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.

That’s a good test @bradstewart!

we have a mix of OS versions now, most devices are running 2.0.8, we have some 2.3.0 too.

The device that had the problem last weekend was on 2.0.3 dev.

Well the plot thickens.

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.

1 Like


have you tried setting autoconnect-retries=0 in your connection configuration file to see if that helps?
You can read more about the network configuration here:

and you can read more about the NetworkManager options here: https://developer.gnome.org/NetworkManager/unstable/nm-settings.html

Is it possible in any way to update this remotely? The gateway experiencing this problem is unfortunately 3 hours by plane away from our office.

1 Like

I see…
I’m not sure if there is a way to perform this action remotely. I’ll ask the team to see if I can get more suggestions.

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).

Also, I wonder if this is a power savings problem.