forwarding ARP reply on bridge device

Question

This is my network:

[laptop A]~~~~[ddwrt1]~~~~[ddwrt2]----[desktop B]
               |
               +--[desktop C]

The ddwrt2 is a wifi router running in client bridge mode connecting to another wifi router ddwrt1. Laptop is connected to ddwrt1 using wifi. The two desktops are connected with Ethernet wire to the wifi routers.

The problem:

• laptop A cannot ping to desktop B, not even have the ARP resolved
• if we set a static ARP entry in laptop A for desktop B, then laptop A can ping B
• same issue with desktop C

So the IPv4 routing is OK here but for some reason ARP packets are not. So I did some debug and found the following:

• all Ethernet LAN and wifi interfaces on ddwrt1 are combined as a bridge device br0
• Running tcpdump -i br0 -e -n -vv arp on ddwrt1 shows the ARP request (broadcast) and response (unicast) packets and all fields look correct
• Running tcpdump on laptop A does not see the response coming back
• Ping desktop B on ddwrt1 is OK
• brctl showmacs on ddwrt1 shows all mac addresses concerned here, at the correct interface
• ddwrt1 has nothing suspicious: bridge-nf-call-iptables and alike sysctl items are off, no ebtables nor arptables running, iptables has no rules about arp

What can I do now? I think I boiled down to the issue of why the bridge cannot forward the ARP reply packet

Answer 1

After some more debugging, I found the answer for this. It is specific to dd-wrt's Linux kernel, see here for the code in arp.c

So there is a "ARP spoofing protection" code in the kernel dropping my reply packets. I can turn it off on the AP's firewall configuration page, or do echo 0 > /proc/net/arp_spoofing_enable in it. If we turned it off, the issue is gone.

The issue it hited is that the ARP reply is relayed from ddwrt2 as wifi frame, so carrying the wifi's MAC instead of desktop B's MAC. This triggered the spoofing protection code referenced above.