[Bridge] Re: Any way of knowing a packet's been defragmented

Henrik Nordstrom hno at marasystems.com
Thu Aug 5 07:53:58 PDT 2004

On Thu, 5 Aug 2004, Eble, Dan wrote:

> IMO, the driver should not bridge any packets from a device with a
> larger MTU to a device with a smaller MTU, which I suppose is almost the
> same as forbidding such a bridge to be created, but I seem to remember
> Stephen's commenting that the 802 bridge spec says it should be done the
> way it is now.

A bridge dropping large frames is plain bad imho. If such bridge exists on 
an IP network then IP won't work as the bridge kills Path-MTU discovery.

I do understand why this check exists in the bridge code to cover all 
cases, but I question the location. The check should be after all 
netfilter hooks just before the packet is given to the NIC driver, dropped 
on transmit because it can not be sent out on the target media, not 
dropped in "bridge forwarding" because it seems to be bigger than the 
intended target device.  This way the check will see the packets 
refragmented by iptables etc as applicable. This will also make it deal 
better with a number of other cases where packets is modified in netfilter 
hooks to other sizes than the original size.

> If connection tracking is coalescing ethernet packets into a size
> greater than would otherwise be received from a device, then connection
> tracking should be responsible for undoing that damage (where and when,
> I don't know), otherwise the ethernet bridge driver will become a
> monstrosity of stuff unrelated to ethernet.

This is how connection tracking works.

The issue here is that this collides with how the bridge currently is 
dropping large frames, causing the bridge code to think the frame is 
oversized even when conntrack will refragment the packet before it is sent 
out on the wire.


More information about the Bridge mailing list