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.