On Thu, Dec 06, 2001 at 02:21:25PM -0700, Ben Greear wrote: > > 2. Add members ->physindev and ->physoutdev to struct sk_buff. This is > > necessary for 'interface transparency'; the ability to filter on enslaved > > devices in iptables rules transparently. For example, if eth0 is enslaved > > to br0, and a packet comes in from eth0, destined for the local machine, > > > > iptables -A INPUT -i eth0 -j DROP > > > > would drop the packet if you have interface transparency. It's easy to > > see that in this case, you need to keep at least one extra variable with > > the sk_buff to make the mentioned rule work. In the case of a locally > > originated packet, you also need at least one extra member. In the case > > of an IP-forwarded packet with both source and destination interfaces > > being bridge interfaces (sounds somewhat artificial, but there actually > > are such setups), you need two. > > Does this scheme still work if you go: eth0 -> vlan5 -> br0 > (Does vlan5 or eth0 count as the physindev?)
I'm not familiar with how your vlan stuff works.. is 'vlan5' a kind of bridge device in itself? Or is it just tagged VLAN 5 over eth0? Currently, the bridge-nf patch uses as physindev skb->dev from-when-the- packet-was-passed-to-the-bridge-code in net_rx_action. So, it all depends on which device you enslaved to br0. In the above scenario, it would look like 'vlan5' is the one. cheers, Lennert _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
