Raspberry pi cannot ping router or internet addresses over wifi bridge

Question

I recently set up a WNR2000v3 router running DD-WRT as a sort of repeater bridge using the "Atheros" version of this tutorial (we'll call this 'router 2'), which is repeating a Medialink Wireless-N router (we'll call this 'router 1'). This works perfectly for my android phone and Windows computer both over the wifi and when directly connected via ethernet, but when I plug in my Raspberry pi, either when running Raspbian (wheezy) or Raspbmc, I cannot get any connection outside the local network.

The raspberry pi can ping (and be pinged by) any of the other devices on the local subnet, including 'router 2', into which it is directly connected, and it's able to get DHCP from the router 1, but when I try and ping router 1, I get "Destination Host Unreachable", and if I try pinging anything on the internet like google.com, superuser.com, I similarly get "Destination Host Unreachable".

Here's another computer on the network:

ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_req=1 ttl=127 time=38.7 ms
64 bytes from 192.168.0.100: icmp_req=2 ttl=127 time=1.67 ms
64 bytes from 192.168.0.100: icmp_req=3 ttl=127 time=1.73 ms
64 bytes from 192.168.0.100: icmp_req=4 ttl=127 time=3.56 ms
--- 192.168.0.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 1.672/11.418/38.705/15.772 ms

Here's router 1:

ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.107 icmp_seq=1 Destination Host Unreachable
From 192.168.0.107 icmp_seq=2 Destination Host Unreachable
From 192.168.0.107 icmp_seq=3 Destination Host Unreachable
From 192.168.0.107 icmp_seq=4 Destination Host Unreachable
From 192.168.0.107 icmp_seq=5 Destination Host Unreachable
From 192.168.0.107 icmp_seq=6 Destination Host Unreachable
--- 192.168.0.1 ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7007ms
pipe 3

192.168.0.107 is the address of the Raspberry Pi:

ifconfig
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:db:c9
          inet addr:192.168.0.107  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3753 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1262 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:595127 (581.1 KiB)  TX bytes:112407 (109.7 KiB)

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:285 errors:0 dropped:0 overruns:0 frame:0
          TX packets:285 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:27703 (27.0 KiB)  TX bytes:27703 (27.0 KiB)

Here is the routing table:

sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

And here is the DHCP request:

sudo dhclient -v eth0
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/xx:xx:xx:xx:db:c9
Sending on   LPF/eth0/xx:xx:xx:xx:db:c9
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
RTNETLINK answers: File exists
bound to 192.168.0.107 -- renewal in 274691 seconds.

Everything else works fine, but I've tried this rapsberry pi with two different images (Raspbmc and raspbian) and two different raspberry pis and no configuration works. The raspbian image has been tested as working when directly connected to Router 1. This problem seems very similar to this unanswered question from two years ago, except that in that case it seems that he was using wifi for the device that failed to connect, and he was actually getting some intermittent connectivity. Also the ping response there was from the router, not the device. What could be causing this problem?

Edit: I should also note that the two different raspberry pis had different IP addresses, one of which was IP-MAC bound, and there were no IP collisions that I saw in the DHCP table, but the same problem on each.

Update: I have determined one potentially interesting thing, which is that when MAC Address Cloning is turned off, the repeater bridge ceases to function - the only thing that can ping the raspberry pi is router 2, and there's no connectivity (or access to router 1) from anything connected only to router 2 - including the Windows machine. However, the mac address that is being cloned is the same mac address that is actually used by the interfaces of router 2 anyway (according to the "status" page). I have power cycled both router 1 and router 2 twice and it makes no difference. I do not understand why MAC address cloning is relevant here. With MAC Address cloning off, when I ssh into the router itself, the router can ping the Raspberry pi, but not router 1.

One other small thing is that when MAC Address cloning is on and I can actually ping other computers on the network, arping returns the same mac address for every device that's responding to pings.

Update 2: From checking the syslog values, I found that there was this error message relating to the MAC address:

Jan  1 00:00:08 Router 2 kern.err kernel: [    6.770000] ath: eeprom contains invalid mac address: ff:ff:ff:ff:ff:ff
Jan  1 00:00:08 Router 2 kern.err kernel: [    6.780000] ath: random mac address will be used: fa:55:da:33:19:a9

Apparently this is a known problem that people are solving using MAC address cloning. I'm not exactly sure why the random MAC addresses are a problem, and what other consequences MAC address cloning is having.

Answer 1

+1 for the detailed problem description.

As I suggested on the thread you opened in raspberry pi , you could check if your main router is listed in the RPi's arp table : arp -n or if you have the iproute2 installed: ip neigh.

If needed you can add the router in the arp cache with this command : arp -s <ROUTER_IP> <ROUTER_MAC> and see if you still have the problem

You can also check if your RPi sends the ARP request as expected by sniffing all the ARP packets. On your RPi, run : tcpdump arp

You could also run the same command on the DD-WRT repeater and on any other host connected on router 1. As the ARP requests are broadcasted you should see them across your lan.

Answer 2

I had the same issue when installing new Wifi Repeater. The compromised solution is set the static IP for Raspberry Pi.

Answer 3

This is a tricky one to diagnose, because of course your system seems correctly configured. So, rather than go through a lengthy list of check options, I will give you some ideas for things to test.

One thing I would try is to change the default gateway to the router 2, rather than router 1.

Another thing is to force ping to bind to the interface eth0:

 ping -I 192.168.0.107 192.168.0.1
 ping -I eth0          192.168.0.1

These two commands are slightly different, both should be tried. Hopefully, they will give different outputs, which would be an indication of a fault.

Then I would check /etc/network/interfaces: does it contain a couple of lines like

  auto eth0
  iface eth0 inet dhcp

Then I would try re-starting the interface:

  ifdown eth0
  ifup eth0

and then dhclient again.

When all is said and done, one should keep in mind that it need not be a software problem. If you go to this Web page you may read the following experience:

I had ordered another raspberry pi and just re-imaged the sd card, booted up in that one, and the internet worked fine. I took the sd card out and put it in the old raspberry pi and hooked up the same exact cables and ethernet cord but it still didn't work....

Also, you should keep in mind that there is the possibility of a problem with the cable. Cables are not working/not working objects. A problem in RX or TX may cause many frames to be dropped, the signal quality to be marginal, and so on. In this case, protocols like TCP behave better than ICMP or UDP because they re-transmit packets which have not been received by the target, giving you the wrong impression of a properly working connection. This wrong impression lasts until you measure the connection speed, of course.

Answer 4

Similar problem I had some time ago. My solution was editing /etc/resolv.conf file by adding nameserver 8.8.4.4, and by restarting interfaces using /etc/init.d/networking restart. It works for me.