From: David Miller <davem@davemloft.net>
To: fw@strlen.de
Cc: tobias@strongswan.org, netdev@vger.kernel.org,
herbert@gondor.apana.org.au, mleitner@redhat.com
Subject: Re: Problems with fragments since gso skb forwarding changes in virtual environment
Date: Mon, 07 Apr 2014 20:05:35 -0400 (EDT) [thread overview]
Message-ID: <20140407.200535.1263628364222611722.davem@davemloft.net> (raw)
In-Reply-To: <20140407234640.GB31953@breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 8 Apr 2014 01:46:40 +0200
> Looking at br_nf_dev_queue_xmit() in br_netfilter.c I see that it has
> a bug (not related 'gso skbs in forwarding path' change): it assumes
> that if skb->nfct is NULL no reassembly has taken place. Thats not
> true (can load ipv4 defrag module without ipv4 conntrack one), or
> netfilter defragmented the packet but then protocol tracker returned
> error ('INVALID' conntrack state in netfilter speak).
>
> I admit its rare condition, but afaics br_nf_dev_queue_xmit is
> supposed to re-fragment packets that have been subject to defrag.
In fact, judging by commits:
commit e179e6322ac334e21a3c6d669d95bc967e5d0a80
Author: Bart De Schuymer <bdschuym@pandora.be>
Date: Thu Apr 15 12:26:39 2010 +0200
netfilter: bridge-netfilter: Fix MAC header handling with IP DNAT
and subsequently:
commit c197facc8ea08062f8f949aade6a33649ee06771
Author: hummerbliss@gmail.com <hummerbliss@gmail.com>
Date: Mon Apr 20 17:12:35 2009 +0200
netfilter: bridge: allow fragmentation of VLAN packets traversing a bridge
I would say that we should simply remove the skb->nfct check
altogether and everything will work fine.
next prev parent reply other threads:[~2014-04-08 0:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-07 16:04 Problems with fragments since gso skb forwarding changes in virtual environment Tobias Brunner
2014-04-07 23:46 ` Florian Westphal
2014-04-08 0:05 ` David Miller [this message]
2014-04-08 0:26 ` Florian Westphal
2014-04-08 12:24 ` Tobias Brunner
2014-04-08 14:33 ` Florian Westphal
2014-04-08 15:36 ` Florian Westphal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140407.200535.1263628364222611722.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=herbert@gondor.apana.org.au \
--cc=mleitner@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=tobias@strongswan.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.