15

I am running my Raspberry Pi headlessly, connecting via SSH over the network. I am having a problem that I can consistently reproduce. I will leave a Python script running on my Raspberry Pi and come back a few hours later and SSH connections to the Raspberry Pi will time out.

If I ping it I get the following:

C:\Users\andrew>ping 192.168.1.42

Pinging 192.168.1.42 with 32 bytes of data:
Reply from 192.168.1.46: Destination host unreachable.

The only way I can get it back on the network is to restart it (pull out the power).

Has anyone experienced this? Are there any log files I can look at to diagnose the issue?

toyota Supra
  • 560
  • 2
  • 6
  • 9
Andy Smith
  • 432
  • 1
  • 5
  • 19
  • 1
    On a raspberry, I have only a cronjob running a python script, and it too will die after a few hours up to 2 days. I cannot SSH it anymore, only a restart by cutting power will help. – k0pernikus Feb 24 '13 at 10:52
  • @k0pernikus interesting! I am trying now running it with with the scren attached, so far (4 hours and counting) and it hasn't failed. Are you using screen at all? – Andy Smith Feb 24 '13 at 12:51
  • what's in your /etc/network/interfaces? Anything scary in dmesg? How is RPI connected to the network? Via a router? What's in the router's logs? If you re-plug the ethernet cable to RPI, will it bring it back to the network? – abolotnov Feb 25 '13 at 16:00
  • @abolotnov I'm actually finding this now if I run the RPI with a monitor attached - it seems to take longer, but when I come back after 6 or so hours it will be unresponsive. dmesg seems clear. – Andy Smith Feb 26 '13 at 07:26

5 Answers5

9

The wireless device goes to sleep after a period of no activity. It's a powersaving scheme.

You need to turn off the powersave feature of wlan0.

I'm using an edimax wireless usb receiver:

Bus 001 Device 005: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

It uses the 8192cu module in the kernel.

To turn off powersave, add the following to /etc/modules, or create a file (8192cu.conf) in /etc/modprobe.d/ with the line(s):

# prevent power down of wireless when idle
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

Next reboot (or rmmod/insmod) it should disable the sleepy mode and your pi will be accessible all the time.

I create the file for /etc/modprobe.d and it's part of a script I built to do preliminary setup on a new build.

lornix
  • 1,066
  • 8
  • 13
  • 2
    This was on a wired network – Andy Smith Jun 10 '13 at 08:35
  • Unfortunately, I have the same problem with these features turned off. Wireless adapter still gets turned off after a number of hours of inaction. – StasM Jul 31 '13 at 07:31
  • I am curious as to whether they're actually turned off. The modprobe.d files much be named particularly (x.conf) and spelling counts (as always). Is your wireless adapter a 8192cu unit? perhaps you need a different module? – lornix Aug 01 '13 at 06:52
  • @lornix: What command did you use to print out the type of wireless receiver you are using? – David Norman Aug 14 '14 at 15:08
  • 1
    lsusb and lsusb -v are very helpful. Figuring out which module isn't always easy, There are ways to match up output of modinfo 8192cu to the vendor:product numbers in lsusb output. – lornix Aug 15 '14 at 01:36
  • I added above line to /etc/modules, right after snd-bcm2835 (which was the only existing entry). Result when booting up was "[info] loading kernel module options" next line "FATAL: Module options not found" – joedotnot Jan 27 '15 at 11:12
  • Following on from my previous comment: it does work, however, on the /etc/modprobe.d/8192cu.conf file !! It is worthy to note that BEFORE i created this file, iwconfig reported Power Management:off (which was incorrect!) – joedotnot Jan 27 '15 at 11:41
2

The problem for me was power management on the wifi as well, but I was not using a 8192cu chipset, so the instructions in the other answer didn't work for me.

Run iwconfig and look for the line that starts with power management

If it says that power management is on, you can turn it off with:

iwconfig wlan0 power off

N Reed
  • 121
  • 3
2

It is common for a router to disconnect inactive clients to free up router resources. This can happen at random times if the client has not been active.

Pete Cranwell
  • 21
  • 3
1

I discovered that extensively ping-ing does bring up the wifi-connection again in my case. I observed that after the 70-100th ping the Pi starts responding and after that a ssh-connection can be initiated successfully.

Edit Turn power save off

iw wlan0 set power_save off

Click here for details.

participant
  • 951
  • 2
  • 7
  • 20
0

Earlier Raspberry Pis had issues with the wireless power management. Other answers have covered this. The power management can be turned off (until reboot) with iwconfig wlan0 power off or iw wlan0 set power_save off to check whether this helps.

Old Raspberry Pis that use ifupdown configure the wlan0 interface in /etc/network/interfaces. In those machines the setting can be made permanent by adding wireless-power off under the wlan0 definition. In newer machines you may be able to disable it by configuring the kernel module in /etc/modprobe.d/. Note that there are several different Realtek wireless drivers that your system may use: 8192cu, rtl8192cu, rtl8xxxu. You can alternatively type crontab -e and add the following line, making the command to be called at reboot:

@reboot sudo iw wlan0 set power_save off

Raspberry Pi 4 shouldn't have the same problem with power management, but there's another issue with dhcpcd that recent Pis use for configuring network interfaces. If you can connect a keyboard and a monitor, check whether dhcpcd is running (systemctl status dhcpcd). It may happend that dhcpcd is killed wtih SIGSEGV when running Docker containers that define virtual networks. In this case you should see the following message when you type grep dhcpcd /var/log/daemon.log:

systemd[1]: dhcpcd.service: Main process exited, code=killed, status=11/SEGV

The solution is to disable dhcpcd for virtual networks. Add the following line to /etc/dhcpcd.conf:

denyinterfaces veth*
Seppo Enarvi
  • 101
  • 1