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;
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. Setup: FreeBSD5 Linux Bridge FreeBSD4 xl0 ----10base2---- eth2 eth0 ----100baseTx---- fxp0 The FreeBSD machines are attempting to talk NFS with each other, the machine on the left sends a read request, which is bridged, and the machine on the right sends a fragmented UDP packet of 8K, this is as observed on eth0: 14:33:59.320397 192.168.0.49.1749359354 > 192.168.0.2.2049: 108 read fh 985,985790/5042 8192 bytes @ 0x000000000 14:33:59.321676 192.168.0.2.2049 > 192.168.0.49.1749359354: reply ok 1472 read (frag 8235:1480@0+) 14:33:59.321798 192.168.0.2 > 192.168.0.49: (frag 8235:1480@1480+) 14:33:59.321922 192.168.0.2 > 192.168.0.49: (frag 8235:1480@2960+) 14:33:59.322044 192.168.0.2 > 192.168.0.49: (frag 8235:1480@4440+) 14:33:59.322169 192.168.0.2 > 192.168.0.49: (frag 8235:1480@5920+) 14:33:59.322215 192.168.0.2 > 192.168.0.49: (frag 8235:928@7400) This traffic will only appear on the other interface when bridge-nf-call-iptables is 0. Am I missing something in my setup; what kernel options should I check, or is there some incompatibility between bridge-nf-call-iptables and fragmented traffic? .config options containing BRIDGE are: CONFIG_BRIDGE_NETFILTER=y # CONFIG_BRIDGE_NF_EBTABLES is not set CONFIG_BRIDGE=y Thanks in advance, -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
Maybe Matching Threads
- [Bridge] Any way of knowing a packet's been defragmented
- [Bridge] [PATCH net-next] net/bridge: add drop reasons for bridge forwarding
- [Bridge] RFC: [PATCH] bridge vlan integration
- [Bridge] [PATCH][RFC] net/bridge: add basic VEPA support
- [Bridge] [PATCH][RFC] net/bridge: add basic VEPA support