RPi occasionally not responding to connections (WiFi)

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

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

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

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

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.

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

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.

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

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

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

Something to do with ARP / MAC address resolution not working properly from my experience.
I haven't been able to solve it yet.

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.

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

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

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

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.

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.

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.

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