Lennert Buytenhek wrote:
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?
It definately isn't a bridge...much more like the latter. For that reason,
it's good that your bridging stuff works :)
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.
Good. I think that is probably the right way for things to work because
you can not have more than one ethernet device feed a particular
vlan device...so for firewalling reasons there should be little reason to
distinguish the physical (eth0) device while using VLANs...
Ben Greear <greearb@xxxxxxxxxxxxxxx> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear