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. Regards Henrik
