I am using an Ubnt LS2 with a recent build of 8.09.  The eth0 interface is an IC+ IP175C bridge with 2 physical ports.

SETUP:
PC A/Modem has 192.168.1.1/24 - connects to eth0 port0 (wan port) - eth0.1
PC B/local PC has 192.168.1.10/24 - connects to eth0 port4 (lan port) - eth0.2
No PC - connects to ath0 (wireless) - ath0
br0 gets a dhcp address and has eth0.1, eth0.2 and ath0 attached.
br0:1 has 192.168.1.2/24

BROKEN:
Ping from B to A

WORKING:
- ssh from B to 192.168.1.2 (openwrt)
- then start ping from openwrt to PC A
At this point the arp entry in the openwrt box for A is correct and present

BROKEN:
- Follow working setction and then start a ping from B to A
At this point the ping from openwrt box to A stops, the arp table the entry for A is now gone
Stopping the ping from B to A will cause it to start working again and the arp entry to reappear.

It has been suggested in IRC that I am creating a loop between eth0.1 and eth0.2 through the switch back plane and the software bridge, but that would mean that the vlans on the switch are not actually keeping layer to traffic separate.  If I take out the vlans and just have eth0 it works but I want to run hostapd (wpa2 with a remote freeradius server) on eth0.1 (lan) and ath0 (wireless).

Can anyone confirm that this is a bug?  Any suggestions on how to isolate if it is an issue with the bridge , vlans, arp or the switch?  Any suggestions on another way to set things up to have authentication on the lan and wireless interfaces while leaving the wan interface?

I am experiencing a very similar problem.

I set up two VLANs on Port 3 and 4 of a TL-WR1043ND (Backfire RC-4) as eth0.3 and eth0.4.
Both I bridge in an attempt to form one unified LAN.

The reason why I do this is that I need the Openwrt-Router to act as a switch that allows packet sniffing between a PC and a server: eth0.3 and eth0.4 should plug between a formerly closed ethernet connection and act totally transparent while allowing tcpdump to dump packets to an attached USB storage device.

I use two separate VLANs instead of just one, because the learning switches would not pass all data to port 5 of the router, but switch most directly, once they've learned the attached device's MAC addresses.
The creation of two seperate VLANs should force all packets up through the software switch.

What I see when comparing wireshark-logs from an attached PC to the tcpdump from the OpenWRT-bridge, is that most packets flow correctly as they should.
I see broadcast ARP-requests coming through to the PC from the LAN, and so are SMB packets, VRRP packets, STP-packets, etc.

However some packets (namely directed ARP requests, DHCP responses etc.) are arriving at OpenWRT's bridge, but they are not being passed to the attached PC.
I can see them in the tcpdump-file, but they're not arriving at the PC.

Apparently, the router filters them out.
I did disable the firewall, ("/etc/init.d ... stop") but that doesn't improve the situation.

Can anyone confirm that this is a bug or point me to a mistake I may have made?

(Last edited by sborilla on 14 Jan 2011, 13:55)

sborilla, thanks for the responce. yeah sounds very similar.  tcpdump on my system revealed that arp requests are making it to A and the responses are being sent back and reach as far as eth0.2 but don't make it to the back to A.  I have even flushed all of the iptables to make sure nothing is blocking them there.

What switch chip is in the TL-WR1043ND?  Can you check dmesg?  If it's not the IC+ IP1750C then that should eliminate the switch backplane as the cause.  Sounding like an issue with the software bridge.  Thanks for letting me know that this seems to be in backfire as well.  Saves me the time of upgrading.

Was trying to use iptables with "-j LOG" to see if I could tell how far the packets are getting.  But was only able to get ICMP packets from the openwrt box to log when I put the rule on nat/POSTROUTING.  So does the bridge bypass iptables or what?

Switching, in my configuration, should be purely software switching (that was why I did the complicated VLAN set-up).

The switch is a Realtek rtl8366rb device, and my /etc/config/network configuration looks like this:

The simplest way to find the deviation is when comparing the PC's Wireshark log with the router's tcpdump.

The PC, for example, sends a DHCP Request, succeeded by a DHCP Discover. Those packets, by nature, are broadcast packets from 0.0.0.0 to 255.255.255.255.
The Router does receive them, they are contained in the tcpdump.
The Router then, 40-41 milliseconds later, receives DHCP offers from four servers. Those packets, by nature, are directed at the newly assigned IP. They're certainly all the same IP.
The PC does not receive any of them.
The PC's Wireshark log only shows the Request/Discovers, but not the responses that the Router still saw.

That means the bridge ("br-sniffer") and the corresponding interfaces eth0.3 and eth0.4 have indeed received the Request/Discover and they habe indeed forwarded their broadcast as they should. They do receive answers, but those they choose not to send to the PC.

Why is that?

I have no clue what I may be doing wrong - or what makes the packets so special, other than them being directed an an IP rather than broadcasts.

Any idea?

I hoped it would - so I understand the bridging functionality.

But for whatever reason the bridge seems to try to isolate both segments from each others - that exactly is creating the problems I observe.

https://dev.openwrt.org/ticket/8653

I'll then open another post to address "my problem", since yours seems to point specifically at ARP tables now.