Networking – Raspberry pi cannot ping router or internet addresses over wifi bridge

dd-wrtnetworkingraspberry pirouter

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,, I similarly get "Destination Host Unreachable".

Here's another computer on the network:

PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=127 time=38.7 ms
64 bytes from icmp_req=2 ttl=127 time=1.67 ms
64 bytes from icmp_req=3 ttl=127 time=1.73 ms
64 bytes from icmp_req=4 ttl=127 time=3.56 ms
--- 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 ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable
From icmp_seq=3 Destination Host Unreachable
From icmp_seq=4 Destination Host Unreachable
From icmp_seq=5 Destination Host Unreachable
From icmp_seq=6 Destination Host Unreachable
--- ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7007ms
pipe 3 is the address of the Raspberry Pi:

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:db:c9
          inet addr:  Bcast:  Mask:
          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:  Mask:
          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         UG    0      0        0 eth0   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

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 port 67
RTNETLINK answers: File exists
bound to -- 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.

Best Answer

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