内核网络实验：桥接tap1与tap2后ARP包无法转发至tap2求助

Hey there! As someone new to kernel networking, it's totally normal to hit little roadblocks like this when experimenting. Let's walk through some key checks to figure out why your ARP packets aren't showing up on tap2:

1. Verify Tap Interfaces & Bridge State #

First, make sure your setup is properly configured at the link layer:

• Check if tap1 and tap2 are actually attached to br0 and in an up state with:

  ip link show br0
  bridge link show br0
  

• Ensure both tap interfaces are in promiscuous mode—bridges need this to receive packets not addressed to their own MAC:

  ip link set tap1 promisc on
  ip link set tap2 promisc on
  

2. Validate ARP Packet Content #

Bridges forward based on MAC addresses, so your injected ARP packet might not be targeting the right destination:

• In Wireshark, inspect the Ethernet frame header of the packet on tap1:
  • Is the destination MAC address set to tap2's MAC, or the broadcast MAC (ff:ff:ff:ff:ff:ff) for an ARP request?
  • If it's a unicast ARP, double-check that the target IP in the ARP payload maps to tap2's IP (confirm with ip addr show tap2).

3. Audit Your ebtables Rules #

Since you mentioned adding ebtables rules (via su -c ...), let's make sure they aren't blocking traffic:

• First, temporarily flush all ebtables rules to rule out misconfiguration:

  su -c 'ebtables -F'
  

• Test if packets flow to tap2 now. If they do, your original rules were likely blocking forwarding.
• If you want to keep rules, list them to check for errors:

  su -c 'ebtables -L -v'
  

  Look at the pkts column to see if your ARP packets are matching any rules—if not, your rule syntax or direction (input/output/forward) might be wrong.

4. Check Bridge-NF Sysctl Settings #

Linux bridges can interact with iptables/arptables via bridge-nf modules, which might block traffic unexpectedly:

• Check the current settings:

  sysctl net.bridge.bridge-nf-call-iptables
  sysctl net.bridge.bridge-nf-call-arptables
  

• If either returns 1, temporarily disable them to test:

  sysctl -w net.bridge.bridge-nf-call-iptables=0
  sysctl -w net.bridge.bridge-nf-call-arptables=0
  

  These settings can cause your ARP packets to be filtered by IP/ARP tables even if ebtables is configured correctly.

5. Confirm libpcap Injection Method #

Make sure your libpcap program is sending packets correctly into the bridge's forwarding path:

• Ensure you're injecting the packet into the correct interface (tap1) and using a valid link-layer header (a complete Ethernet frame, not just an ARP payload).
• Double-check if you're using pcap_sendpacket() or pcap_inject() correctly—some older libpcap versions might have quirks with tap interfaces.

Start with these steps, and you'll likely spot the root cause quickly!

内容的提问来源于stack exchange，提问作者SPMP