RPi occasionally not responding to connections (WiFi)


23 posts
by unpaiktable » Tue Feb 12, 2013 1:20 am
Hi,

I have done extensive searching to find similar issues to my problem but without any luck. I have a RPi (256MB, Model B, 32GB Class 4 SD) setup with Wheezy:
Code: Select all
Linux hail 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux


I tried setting my WiFi IP to static, which worked fine for the first few days but the problem came back. I did a rpi-update two days ago but the problem didn't go away. Here's the issue:

Once the RPi boots up, it all works fine and I can SSH to it, and connect to the MPD server which is running. I can even access it from outside my home network using dyndns. After a while, usually it's half a day or maybe more, I can no longer connect to the RPi, even though it's functioning properly.

SSH connection attempts report:
Code: Select all
ssh: connect to host 192.168.1.105 port 6601: Host is down
, while trying to connect to MPD I get this:
Code: Select all
Couldn't connect to MPD (host = 192.168.1.105, port = 6600): No route to host


I am using an iPad Mini power supply, and the only USB device connected to the RPi is the Edimax EW-7811UN WiFi module.

When I connect a keyboard and a monitor to see what is going on, the RPi is working fine with the exception of responding successfully to incoming connection requests. Normally, this is fixed with a reboot or if I send a few connection requests (SSH or MPD Client) and then I wait a little bit and it's back to responding successfully again.

Any pointers would be more than welcome, unfortunately I haven't got a clue what to use other than dmesg for troubleshooting. I would appreciate your help, even if it's just a "read this" or a "paste the output of this and that command here".

Thank you in advance
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by SirLagz » Tue Feb 12, 2013 8:50 am
Run this in a terminal, and paste back what comes up when you can't access the pi over wifi
Code: Select all
wpa_cli


Also, when it's down, run ifconfig and paste the output in here too
My Blog - http://www.sirlagz.net
Visit my blog for Tips, Tricks, Guides and More !
WiFi Issues ? Have a look at this post ! http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=44044
Posts: 1704
Joined: Mon Feb 20, 2012 8:53 am
Location: Perth, Australia
by unpaiktable » Tue Feb 12, 2013 10:45 am
Hi, thanks for the reply. I shall do what you advised me to do. I tried testing the command you gave me just to test its output, and it's giving me this:
Code: Select all
pi@hail ~ $ wpa_cli
wpa_cli v1.0
Copyright (c) 2004-2012, Jouni Malinen <j@w1.fi> and contributors

This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.

Alternatively, this software may be distributed under the terms of the
BSD license. See README and COPYING for more details.


Could not connect to wpa_supplicant - re-trying
I am running this over an ssh session, connecting over WiFi. Doesn't look normal, does it? Also, here's the output of ifconfig:
Code: Select all
pi@hail ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:f4:13:e4 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:824 errors:0 dropped:0 overruns:0 frame:0
          TX packets:824 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:94245 (92.0 KiB)  TX bytes:94245 (92.0 KiB)

wlan0     Link encap:Ethernet  HWaddr 80:1f:02:68:c9:23 
          inet addr:192.168.1.105  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:661982 errors:0 dropped:694918 overruns:0 frame:0
          TX packets:575743 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:531893480 (507.2 MiB)  TX bytes:512470872 (488.7 MiB)


Thanks
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by unpaiktable » Tue Feb 12, 2013 11:00 am
Doing a ps -ef I can see though that wpa_supplicant is running:
Code: Select all
root      1459     1  0 10:54 ?        00:00:00 /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid -i w
This was even after a reboot of the Pi. Now I ran again ifconfig and the number of dropped incoming packegs looks like is steadily increasing:
Code: Select all
RX packets:697 errors:0 dropped:818 overruns:0 frame:0
...
RX packets:716 errors:0 dropped:842 overruns:0 frame:0
...
RX packets:730 errors:0 dropped:858 overruns:0 frame:0
These were about ~10sec intervals.

Thanks
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by SirLagz » Tue Feb 12, 2013 2:43 pm
unpaiktable wrote:Hi, thanks for the reply. I shall do what you advised me to do. I tried testing the command you gave me just to test its output, and it's giving me this:
Code: Select all
pi@hail ~ $ wpa_cli
wpa_cli v1.0
Copyright (c) 2004-2012, Jouni Malinen <j@w1.fi> and contributors

This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.

Alternatively, this software may be distributed under the terms of the
BSD license. See README and COPYING for more details.


Could not connect to wpa_supplicant - re-trying
I am running this over an ssh session, connecting over WiFi. Doesn't look normal, does it? Also, here's the output of ifconfig:
Code: Select all
pi@hail ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:f4:13:e4 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:824 errors:0 dropped:0 overruns:0 frame:0
          TX packets:824 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:94245 (92.0 KiB)  TX bytes:94245 (92.0 KiB)

wlan0     Link encap:Ethernet  HWaddr 80:1f:02:68:c9:23 
          inet addr:192.168.1.105  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:661982 errors:0 dropped:694918 overruns:0 frame:0
          TX packets:575743 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:531893480 (507.2 MiB)  TX bytes:512470872 (488.7 MiB)


Thanks


Sorry, forgot to mention wpa_cli requires sudo.
The ifconfig looks fine to me, though we need to see if when the wifi connection is not working.
My Blog - http://www.sirlagz.net
Visit my blog for Tips, Tricks, Guides and More !
WiFi Issues ? Have a look at this post ! http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=44044
Posts: 1704
Joined: Mon Feb 20, 2012 8:53 am
Location: Perth, Australia
by unpaiktable » Mon Feb 18, 2013 9:32 pm
Hi again,

At the moment I am trying to SSH to the RPi and am getting this error:
Code: Select all
$ ssh -p 6601 pi@192.168.1.105
ssh: connect to host 192.168.1.105 port 6601: Host is down
(The port number is correct)

I did as you told me and ran wpa_cli and ifconfig on the Pi, so here's the output from both:
Code: Select all
$ cat ifconfig.out
eth0      Link encap:Ethernet  HWaddr b8:27:eb:f4:13:e4 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2121 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:170764 (166.7 KiB)  TX bytes:170764 (166.7 KiB)

wlan0     Link encap:Ethernet  HWaddr 80:1f:02:68:c9:23 
          inet addr:192.168.1.105  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:407 errors:0 dropped:44175 overruns:0 frame:0
          TX packets:63 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29185214 (27.8 MiB)  TX bytes:2122804 (2.0 MiB)
Code: Select all
$ cat wpa_cli.out
wpa_cli v1.0
Copyright (c) 2004-2012, Jouni Malinen <j@w1.fi> and contributors

This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.

Alternatively, this software may be distributed under the terms of the
BSD license. See README and COPYING for more details.


Selected interface 'wlan0'

Interactive mode


After I couldn't SSH from my laptop to my RPi, I tried SSHing from the RPi to my laptop which was successful. Once I did that, I was again able to SSH to the RPi from the laptop. It's a mystery to me. Please let me know if you need more information - your help and time is much appreciated

Thanks
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by SirLagz » Tue Feb 19, 2013 12:47 am
Sounds like the same issue I was having then haha.
Maybe try turning power management on the WiFi adapter off ?
Code: Select all
sudo iw wlan0 power off
I think that's the command.
My Blog - http://www.sirlagz.net
Visit my blog for Tips, Tricks, Guides and More !
WiFi Issues ? Have a look at this post ! http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=44044
Posts: 1704
Joined: Mon Feb 20, 2012 8:53 am
Location: Perth, Australia
by unpaiktable » Tue Feb 19, 2013 1:32 am
Thanks for the reply
Code: Select all
$ sudo iwconfig wlan0 power off
Error for wireless request "Set Power Management" (8B2C) :
    SET failed on device wlan0 ; Operation not permitted.
This is what I get when I run it. Any ideas?

Thanks
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by unpaiktable » Sat Feb 23, 2013 1:03 pm
Hi again, there has been a new development. I think the Raspberry Pi keeps working, even though it's unreachable from my laptop or any other computer. For example, I tried ssh-ing the Pi and got this:
Code: Select all
rain:~ catwoe$ ssh -p 993 pi@192.168.1.105
ssh: connect to host 192.168.1.105 port 993: Host is down
rain:~ catwoe$ ssh -p 993 pi@192.168.1.105
ssh: connect to host 192.168.1.105 port 993: Host is down
rain:~ catwoe$
rain:~ catwoe$ ssh -p 993 pi@192.168.1.105
ssh: connect to host 192.168.1.105 port 993: Host is down
sshd is intentionally configured to listen on port 993. This has been tested before and is working. Not when the Pi refuses to respond to any incoming connections though. This is me pinging the Pi:
Code: Select all
rain:~ catwoe$ ping 192.168.1.105
PING 192.168.1.105 (192.168.1.105): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
Request timeout for icmp_seq 0
ping: sendto: Host is down
Request timeout for icmp_seq 1
ping: sendto: Host is down
Request timeout for icmp_seq 2
ping: sendto: Host is down
Request timeout for icmp_seq 3
^C
--- 192.168.1.105 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss


Running ifconfig on the Pi didn't show any signs of a misconfiguration. I also tried pinging http://www.google.com and that worked fine. I also tried pinging my laptop, from the Pi and that was working too.

This is the a-ha moment. As soon as I pinged my laptop from the Pi, it started responding to incoming connections again, prompting me for password when connecting through ssh.
Code: Select all
rain:~ catwoe$ ssh -p 993 pi@192.168.1.105
pi@192.168.1.105's password:
I don't know what to make of this behaviour, unfortunately. It's something I cannot explain with my knowledge. What could be going wrong?

Please help - thanks
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by unpaiktable » Sat Feb 23, 2013 1:44 pm
The Raspberry Pi started refusing connections again, after a short while. As soon as I started playing some internet radio station using MPD, I was able again to SSH to it. I'm confused :)
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by SirLagz » Sun Feb 24, 2013 7:19 am
Something to do with ARP / MAC address resolution not working properly from my experience.
I haven't been able to solve it yet.
My Blog - http://www.sirlagz.net
Visit my blog for Tips, Tricks, Guides and More !
WiFi Issues ? Have a look at this post ! http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=44044
Posts: 1704
Joined: Mon Feb 20, 2012 8:53 am
Location: Perth, Australia
by unpaiktable » Sun Feb 24, 2013 1:41 pm
I had a suspicion that it was probably my BT HomeHub causing this. But I am able to connect to my laptop either locally or outside my home network. So it could be that there's an incompatibility between the RPi and the Hub.
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by unpaiktable » Sun Mar 10, 2013 9:39 pm
I have set up a dyndns.org address, let's say its me.dyndns.org which I use to connect to my home PCs remotely, as well as the Raspberry Pi which works fine from outside. Here's what's causing me concerns. When I try to SSH from my PC to the Raspberry Pi, if I do:
Code: Select all
ssh 192.168.1.100
it doesn't work and shows the host as being down. On the other hand, if I do
Code: Select all
ssh me.dyndns.org
it works.

Any ideas what could be going on?

Thanks
Posts: 11
Joined: Tue Feb 12, 2013 1:03 am
by Gomoto » Mon Mar 11, 2013 12:39 am
Edimax Wifi works only with powered hub correct for me, several psu tested, including decent ones :-)

try powered hub and tell if problem persists, thanks
Raspberry Pi Model B 512 MB @ 900/250/450 Mhz, 64 MB GPU, Raspian 09.02.13, HDMI 1980x1050
Posts: 96
Joined: Tue Feb 12, 2013 1:21 am
by rigr » Wed Apr 24, 2013 8:03 pm
I think the problem is that the EdiMax adapter is not responding in a timely way to arp requests.

Arp is of course the mechanism by which network devices (like your desktop computer or your RPi) map IP addresses to device MAC addresses. Each network device keeps it own table, and the table is built using broadcast arp requests. It happens under the covers so you don't usually need to be aware of it.

On the Linux box from which you are trying to talk to the RPi, enter the following command:
arp -n

You'll get a listing all known IP/MAC pairs, like this:
Address HWtype HWaddress Flags Mask Iface
192.168.1.93 ether 80:1f:02:49:39:d4 C eth0
192.168.1.98 ether 98:4b:e1:45:6c:39 C eth0

If you've already tried to ssh to your RPi and it isn't in the list, it could be that the RPi did not respond to the broadcast arp request. You can manually add the arp entry on your desktop computer, e.g.:
arp -s 192.168.1.10 00:1d:60:ca:08:58

You can get the IP and MAC addresses of your Rpi by running the ifconfig command on the RPi (make sure you use the numbers from the wireless interface).

Once the arp table has been updated, your ssh will connect normally (that is if you are having the same problem I was).
Posts: 3
Joined: Wed Apr 24, 2013 7:37 pm
by rraszews » Thu May 16, 2013 3:02 pm
I'm having exactly this issue as well. Manually inserting the RPi into the arp table at the other end works, but it's not really a scalable solution if I plan on having lots of these things floating around the house. Is the edimax's failure to arp reliably something we can fix with a configuration/driver change, or should I start experimenting with other wifi adapters?

I don't know if it's relevant, but I've got another RISC linux-based system-on-a-chip dealie, a Chumby One, and it exhibits the same behavior -- I can only reliably connect to it if I manually set the ARP table at the other end manually.
Posts: 3
Joined: Sat Sep 01, 2012 3:09 am
by rigr » Thu May 16, 2013 4:15 pm
I've subsequently discovered that my Edimax WiFi connectivity problems go away if I use a better power supply.

It was not a question of the supply's wattage (I was using a 6W unit), it was the ripple and/or noise in the voltage. The RPi itself has an onboard 3.3V voltage regulator so dirty power is no problem for the processor, but the USB adapters are fed directly from the 5V input. In my case a 330uF capacitor across the power supply smoothed out the voltage enough give me reliable operation of the Edimax adapter.
Posts: 3
Joined: Wed Apr 24, 2013 7:37 pm
by rraszews » Fri May 17, 2013 6:56 pm
Interesting. I've got a battery attached to mine, so I would have thought the power would be fairly clean, but this isn't the first time I've seen unrelable behavior based on the power. Is anyone making some kind of Specifically-rPI-vetted power supply/filter/adapter that promises to give the best possible power to a pi? Even the pages I've read about which power supplies are good haven't brought up the noise issue that I recall.
Posts: 3
Joined: Sat Sep 01, 2012 3:09 am
by rigr » Fri May 17, 2013 8:58 pm
Maybe the power on the 5V rail is disturbed by currents induced by other components on the Rpi itself. In that case a bypass cap would help even when using battery power. You might get away with simply plugging it into the 5V and GND pins in the GPIO header (I haven't tried that personally -- I soldered mine into an add-on board).
Posts: 3
Joined: Wed Apr 24, 2013 7:37 pm
by ibash » Wed Nov 27, 2013 6:43 pm
In case anyone else happens upon this thread -- I had the same issues with the RPi not responding periodically, but if I pinged from the RPi to another part of the network it would respond. I saw the same thing with it not registering in the arp table.

Turned out the issue was the edimax 7811un dongle I was using, it would go into power saving mode. The fix for this is here: viewtopic.php?t=51543&p=397663

Copy/pasting for convenience:
It is possible to set the 8192cu power management parameter to off by generating the 8192cu.conf file with command sudo nano /etc/modprobe.d/8192cu.conf and adding the lines
Code: Select all
# Disable power management
options 8192cu rtw_power_mgnt=0



Make sure you spell that correctly -- I kept on spelling mgmt instead of mgnt and then the 8192cu driver would not load...

Hope that helps! If you want to test it out, clear your arp table from another computer and then try pinging the RPi... in OSX:
Code: Select all
sudo arp -ad
ping <ip address of rasberry pi>


before I would get:
Code: Select all
PING 10.0.0.30 (10.0.0.30): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6


Now I get responses instantly
Posts: 1
Joined: Wed Nov 27, 2013 6:37 pm
by justaguy » Wed Nov 27, 2013 8:46 pm
I've had these same issues with my Pi's, and after reading the post about the wifi going to power saving mode, I got to thinking - I've been using the same model wifi adapter on all of them, so perhaps this is the problem as well.

Mine are Tenda W322U V2.0's. In Linux Mint 15 and in Ubuntu Linux they use the rt2000 driver, if that helps any.

I have absolutely no clue how to do such a command, or what the command would be to my wireless adapter.

Does anyone have any ideas?

Thank you!
Posts: 5
Joined: Wed Nov 27, 2013 8:12 pm
by samlu » Wed Jan 22, 2014 4:15 am
Adding the /etc/modprobe.d/8192cu.conf file solved the problem that I've been having with my Airlink 101 Wifi dongle. Before this change, I would have to 'ping' the RPi for 10 to 30 seconds until it successfully responds to the ARP request.
Posts: 2
Joined: Sat Jul 06, 2013 7:16 pm
by unphased » Mon Apr 28, 2014 2:07 am
I'm not sure what the real cause is, but I reckon the first order of business when investigating a problem like this is checking the voltages.

I have an ath9k wifi chipset, one with a 4 inch antenna, so it's not one of the tiny USB dongles.

When I was experiencing intermittent behavior where I could not get the Pi to reliably respond to ping (and couldn't SSH to it), but where the Pi itself was somehow able to ping Google just fine, the voltage was a bit lower than 4.75v. This is out of USB spec and Wifi adapters don't like that.

I gotta test some more, but bypassing the polyfuse (by using a male A to male A USB cable for instance) we can buy between .07 and .15 volts back, just have to be sure that the input voltage will never spike above 5V. I have a battery eliminator module that spits out 4.94v and a USB battery pack that outputs 5.08v. Both were pretty cheap and are clearly made in China so I don't really trust either of them not to produce transient spikes, and there's no way to vet them without an o-scope... bypassing the polyfuse introduces some risk, and using the microUSB plug introduces the risk of Wifi flaking out. Luckily the Pi model A seems to save quite a bit of power and allows the supply to not droop nearly as low as the model B does.

Of course, now that I am testing it again, and even though it makes the voltage drop down to 4.65v when running iperf, it is functioning just fine. :x
Posts: 20
Joined: Tue Apr 08, 2014 2:44 pm