On Mon, 2 Aug 2004 23:22:00 +0200 Bart De Schuymer <bdschuym@xxxxxxxxxx> wrote: > On Sunday 01 August 2004 14:46, Matthias Andree wrote: > > Hi, > > > > please Cc: all replies, I'm not subscribed > > > > I seem to have troubles with my Linux bridge (2.6.8-rc2), which is > > apparently not bridging UDP fragments (NFS) when passing packets through > > iptables, but I do not see in the iptables stats where the packets are > > dropped. Policies for INPUT, FORWARD, OUTPUT are all "ACCEPT", and I > > grepped for all REJECT and DROP rules in iptables -nvL, their counters > > are constant, i. e. they aren't rejecting or dropping packets. > > The patch below fixes this. > I'm not sure if removing this test, which was recently added, doesn't cause > problems elsewhere. AFAIK if a too large packet arrives at that place in the > code, there is a bug somewhere else. > Stephen, please apply the patch below, except if you think it can cause > problems, in which case we'll need a different approach. > The problem occurs when connection tracking is enabled in the kernel. > Packets are then first defragmented, making skb->len bigger than the mtu. > > cheers, > Bart > > --- linux-2.6.8-rc2-bk9/net/bridge/br_forward.c.old 2004-08-02 23:15:42.000000000 +0200 > +++ linux-2.6.8-rc2-bk9/net/bridge/br_forward.c 2004-08-02 23:15:55.000000000 +0200 > @@ -23,7 +23,6 @@ static inline int should_deliver(const s > const struct sk_buff *skb) > { > if (skb->dev == p->dev || > - skb->len > p->dev->mtu || > p->state != BR_STATE_FORWARDING) > return 0; > I am worried what happens if you bridge a 4K mtu lan to a 1500 mtu lan.. It is likely that the ethernet driver of the smaller mtu lan will oops or hang while trying to send the huge skb. No other code path would hand a huge mtu to a device.