On Monday 01 March 2004 09:35, David S. Miller wrote:
> Let us say that on input, br strips the 4 bytes as you say, iptables looks
> at the thing and rewrites the IP source/destination address or whatever,
> and this causes the packet to actually get forwarded out via a different IP
> route, and let us say that this new IP route causes the packet to go out
> via an IPIP tunnel device, which must do all the same kind of crap the code
> you're patching here does, that is determine the LL header size etc. in
> order to make sure there is enough headroom to slap on the new IP
> encapsulating header.
> If you can show that this kind of scenerio would never be generated in the
> cases where br-netfilter is involved, then fine.
The IPIP code does
so there's no problem there because the macro LL_RESERVED_SPACE uses that
value. There should never be a problem like that with routing.
When routing IP packets, skb->protocol will always be set to ETH_P_IP, so
nf_bridge_pad doesn't do anything.
Obviously, adding a normal Ethernet device and, say, a vlan-enabled device as
bridge ports of the same bridge is bound to give problems because full
Ethernet frames will arrive on the normal device and there's no room to
insert a vlan header before sending them onto the vlan-enabled port. For IP
packets we might be able to fix this when ip_conntrack is loaded by using
fragmenting, but I don't think this currently works. I'll have to experiment.
Note that changing the IP destination in a vlan-embedded packet makes the
bridge code pass the packet up to higher layers (unless it can still be
bridged), but the vlan header is not yet stripped. So only if the bridge
device itself is vlan-enabled, will the packet be able to be routed. But
first the vlan tag will be stripped (by the vlan-enabled bridge device).