I have a few raspberry pi 3 model B's that I use for data acquisition and communication. I occasionally have a need to remote access them, so I have set up an xrdp communication on the pi's, and I use Windows Remote Desktop Connection on my computer (pi's all have a static ip). Once in a while, when I try to access the pi's, I get an 'unable to establish a connection' notification. After many frustrating hours, I installed a network scanning tool to search my network for devices. Interestingly, when I am unable to remote access the pi's, they also drop off from the network scanner. If I manually restart them, they work again. I have a program set up to restart the pi's every day, so I don't think it's a timeout thing. Also, even when the pi's are unaccessable, they still write data to an external website.

Anyone have any ideas about how to stop the pi's from falling off the network? I want to use them in a remote location, so manually restarting them isnt a good workaround for me . Thanks in advance!


I think you might as well blame this on a physical problem with the signal, or weird behaviour of the router that can't be altered, or something else which cannot be fixed directly.

It sounds like it is not serious in the sense that this system is providing services to people and arbitrarily cutting them off. It's mostly idle in terms of network activity, so the cut-offs aren't interrupting anything, they're just leaving the system unreachable.

In which case you just have to make sure the pi knows when it has become disconnected, and get it to reconnect, which is the idea here:

How to automatically reconnect WiFi?

Although I wrote it, I wouldn't recommend using that exact script -- unless you like it, and note although it has evolved quite a bit in the past three years (and that wasn't the first version, either), I still use basically the same thing with everything. Like Milliways, I actually don't have many problems with Pi's; I just checked a Pi 3 that I left in a building several weeks ago, and the log for my reconnection script shows it hasn't had to reconnect at all since then (though there's a Pi 0 w/ a Ralink wifi adapter in the same building that's had to reconnect twice).

The system I have the most trouble with is a laptop with Realtek wifi (if you use linux, don't buy Realtek; I am not alone in this problem...). It will randomly disconnect while I'm using it unless I use an external adapter.

Here's the basic strategy:

  1. Pick an IP that should always be pingable. This could be the router, or it could be Google's public DNS servers at, which respond to pings. Or it could be the external nameserver provided via DHCP. Or a server of yours you trust, etc.

  2. Pick an interval that's appropriate for your use case; it sounds like you could use a few minutes.

  3. Ping the IP at that interval and check if it succeeds. You can do that easily enough in a shell script:

    ping -c 1 
    if [ $? -ne 0 ]; then
        # Ping failed, reconnect.

$? here is the exit status; you should be able to check that in whatever programming language you want to use (although this is one case where shell is probably the simplest).

Ping will return 0 when it succeeds and some positive integer otherwise. Note the -c 1 switch; this is important (see man ping for why). You could also try -w and/or -W if you want, just make sure they work the way you think they do.

When the ping fails, you should do two things:

  1. Ensure that whatever networking service you are using is shut down.

  2. Start the networking service again.

There could be an issue depending on the behaviour of the networking service when it fails to connect. As mentioned in the other answer, my preference is to disable the stock stuff and arrange it myself so the behaviour is totally predictable (keep trying and do not stop trying until a connection is successful), but this is perhaps a bit ignorant of me and you will likely be better off investigating how the stock stuff works (if it doesn't do this by default, it should be an option).

  • Thank you for the feedback. I will definatelly be implimenting a ping-testing script to auto reconnect to the network. – PennStater Mar 4 '17 at 23:48

In my experience when powered by battery devices such as WiFi suffer first when battery is low. You didn't mention the power setup of your pi. If @Milliways solution does not solve it, you could test yet another thing, described in an old Adafruit article modify device power saving settings for raspi 2 wifi The remedy was... Create and edit a new file in /etc/modprobe.d/8192cu.conf

sudo nano /etc/modprobe.d/8192cu.conf

and paste the following in

# Disable power saving
options 8192cu rtw_power_mgnt=0 rtw_enusbss=1 rtw_ips_mode=1

Then reboot.

But this probably does not apply to pi 3.


The Pi should NOT "fall off the network". I have Pi3 running for months with no issues.

When I first try to ssh in after starting a remote computer it can take a while to respond, this is normal.

iwconfig will show settings for your WiFi, generally this includes Power Management:on

Contrary to common opinions this does NOT disable wireless, it is a power saving issue, which influences how often the interface wakes up.

You can try sudo iwconfig wlan0 power off which disables wireless power management.

A common cause of problems with the Pi (including wireless) is poor power supply or power cable.

As you have not specified how you have configured your Pi it is not possible to comment, but poor settings can result in networks becoming unresponsive. The current default, using dhcpcd is very robust.


In my case (RPi 3B+) it helped to update the firmware modules using

sudo rpi-update
sudo reboot
  • It may have helped you but it is not a good general advice because: "In normal circumstances there is NEVER a need to run rpi-update as it always gets you to the leading edge firmware and kernel and because that may be a testing version it could leave your RPi unbootable". raspberrypi.org/forums/viewtopic.php?p=916911#p916911 Even the rpi-update documentation now warns "Even on Raspbian you should only use this with a good reason. This gets you the latest bleeding edge kernel/firmware." – Ingo Mar 19 '19 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.