netdev
[Top] [All Lists]

Re: [PATCH] 2.6.3 fix vlan-encapsulated fragmented IP traffic

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: [PATCH] 2.6.3 fix vlan-encapsulated fragmented IP traffic
From: Bart De Schuymer <bdschuym@xxxxxxxxxx>
Date: Mon, 1 Mar 2004 19:47:51 +0100
Cc: ebtables-devel@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20040301003525.522d6db2.davem@xxxxxxxxxx>
References: <200402291914.53578.bdschuym@xxxxxxxxxx> <200403010806.29759.bdschuym@xxxxxxxxxx> <20040301003525.522d6db2.davem@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.5
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
dev->hard_header_len=LL_MAX_HEADER+sizeof(struct iphdr);
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).

cheers,
Bart


<Prev in Thread] Current Thread [Next in Thread>