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)
Reasonably Related 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