Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm bridging two routers. The primary (attached to the internet) is a stock Linksys WRV200 running Firmware Version: 1.0.39. The secondary is a Linksys WRT-54g running Firmware: DD-WRT v24-sp2 (10/10/09) mini.

I followed the instructions here, trying to create a wireless bridge:

Both routers sit on -- primary is, secondary

I have a Linux box connected by cat5 to the secondary with a static IP address of This can connect outbound (I can ping the primary, and I have internet access on that box). However, when I try to ping from a laptop with a wireless connection to the primary (IP address, I get the following:

$ ping
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable

I can ping from to the secondary router itself -- just nothing beyond it.

Here are the vital statistics of the primary:

Local IP Address:
Subnet Mask:

Running as DHCP server
IP Address Range: through 254

Destination LAN IP | Subnet Mask   | Gateway     | Interface        | |     | LAN&Wireless        | |     | WAN
Default Route (*)  |       | | WAN          |       |   | LOOPBACK

The secondary:

Local IP Address:
Subnet Mask:
Local DNS: {not populated}

Routing table:

Destination LAN NET | Subnet Mask   | Gateway     | Interface         | |     | LAN & WLAN         |   |     | LAN & WLAN             |       | | LAN & WLAN

So... if I'm reading this correctly, the routers aren't actually bridged... the secondary is actually acting as a router, and isn't allowing packets from the primary to reach other side of its network, even though they're on the same subnet.

I did follow the instructions about disabling the firewall on the secondary. Here are the interesting parts of iptables -L (I've removed the empty chains).

Chain INPUT (policy ACCEPT)
target     prot opt source               destination      

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination      
ACCEPT     0    --  anywhere             anywhere         
logdrop    0    --  anywhere             anywhere            state INVALID
TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
lan2wan    0    --  anywhere             anywhere         
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     0    --  anywhere             anywhere            state NEW


Chain logaccept (0 references)
target     prot opt source               destination      
ACCEPT     0    --  anywhere             anywhere         

Chain logdrop (1 references)
target     prot opt source               destination      
DROP       0    --  anywhere             anywhere         

Chain logreject (0 references)
target     prot opt source               destination      
REJECT     tcp  --  anywhere             anywhere            tcp reject-with tcp-reset

I assume that there's something simple that I'm missing here ... how do I set this up so that boxes connected to either router are routable?

share|improve this question
I've set this up before and it worked for me. Did you follow every single step? what router hardware are you using. I did once read that there were some issues with some chipsets working in client bridge mode. – Matt H Apr 30 '13 at 2:35
I don't think that it's a a hardware issue... I had the DD-WRT bridged with a different router this morning... I think that I just have something mis-configured. – Barton Chittenden Apr 30 '13 at 3:00
up vote 1 down vote accepted

It turns out that I did miss one step. The last step of the instructions says

Set your computer back to auto IP and auto DNS.

{This refers to the computer wired directly to the secondary router, i.e. the computer earlier set to, which I couldn't ping}.

As soon as I set this to DHCP, I was able to ping from a machine connected to the primary router. The only thing that I can think of is that the primary couldn't see the MAC address of the machine on the secondary router until it made an ARP request, which it wouldn't have done while it had a static Ip... and yet, I had full network access on that box, so all of its packets would have gone through the primary...

I dunno. I'm going to chalk it up to some strange layer 2 nonsense. If someone can give me a clearer answer, I'll accept it. I want to set up dhcp and dns caching on the secondary router, because DD-WRT has dnsmasq, which is beautiful on home networks... so if ip addresses are only routable after having been registered with the primary router's dhcp server, I'm going to be coming back around to this...


The answer, such as it is, came when I was trying to capture the MAC addresses of all the machines on my network (I was going to use these to set up dnsmasq).

$ sudo nmap -sP | egrep '^(Nmap scan|MAC)'
Nmap scan report for
MAC Address: 00:18:39:08:1D:14 (Cisco-Linksys) # Primary
Nmap scan report for
MAC Address: 00:12:17:12:96:22 (Cisco-Linksys) # Secondary
Nmap scan report for
MAC Address: 00:12:17:12:96:22 (Cisco-Linksys) # Connected to secondary
Nmap scan report for
MAC Address: 90:18:7C:2A:21:C4 (Unknown)
Nmap scan report for
Nmap scan report for
MAC Address: 00:12:17:12:96:22 (Cisco-Linksys) # Connected to secondary

The kicker here is that all of the machines connecting through the secondary share the MAC Address of the secondary.

If I had a true bridge, the two routers would essentially be acting as a single switch (a layer 2 device). Packets from a given device on the subnet would be delivered to another via MAC Address.

That's not what's happening here. Instead, I have two interleaved subnets that have the same IP address space. Ordinarily, this would be a bad idea; if you're not careful, it could lead to IP address conflicts. In this case, it's not so bad, because all of the DHCP requests are handled by the primary router (I have DHCP forwarding set up on the secondary)

Packets from the primary are delivered to the secondary via MAC address. The machines beyond the router are on a second network segment, and therefore do not share MAC addresses with the primary network.

I mentioned that I had previously had the DD-WRT bridged with a different router. This was a true bridge, set up through WDS (Wireless Distribution System). The caveat with WDS is that both routers must use the same chip-set.

At the time that I set it up, I couldn't figure out why that mattered, but once I started thinking about it, it made sense. If I create a bridge between two routers, I'm essentially creating one big switch -- a layer 2 device. A switch has the 'smarts' to deliver packets via MAC address, rather than broadcasting packets and letting each device on the network sort out whether or not to accept them (that would be a hub, rather than a switch). The specifics about how the switch actually delivers packets is a layer 1 (i.e. hardware) decision. Generally, you don't have to worry about the hardware layer, because all of the decisions are made within the same physical machine. You can treat it as a black box. That doesn't work with WDS, because at that point you're trying to mix two boxes at the layer 1 -- i.e. hardware level, and at that level, chip-sets matter.

share|improve this answer

I think I have an explanation for why this is happening, and can explain how I fixed it on my system.

I had a similar situation, two DD-WRT routers connected together (in this situation via powerline ethernet). In my scenario, probably an even stronger case that they are not acting as a single switch.

I was able to get the second router to work by changing the WAN port to be part of the switch, and then connecting the powerline ethernet adapter to the WAN port (in this case eth1). By doing this, the bridging mechanism recognized them as different networks, and routed packets from eth1 to eth0 (where the hard-wired computer was). I hadn't been able to otherwise debug it because the br0 bridge was clearly succesfully routing packets between the wireless ath0 and eth0 networks.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.