All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: nfqueue & bridge netfilter considered broken
Date: Fri, 2 Sep 2016 12:22:44 +0200	[thread overview]
Message-ID: <20160902102244.GB506@breakpoint.cc> (raw)
In-Reply-To: <20160902100021.GA5627@salvia>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Fri, Sep 02, 2016 at 11:58:53AM +0200, Pablo Neira Ayuso wrote:
> > On Fri, Sep 02, 2016 at 11:08:48AM +0200, Florian Westphal wrote:
> > > I - discard extra nfct entry when cloning.  Works, but obviously not
> > >  compatible in any way (the clones are INVALID).
> > 
> > This approach is simple and it would only break when packets are
> > flooded to all ports, actually this is not working anyway because of
> > clashes at confirm, right?
> 
> Hm, what about attaching the notrack conntrack for this case?

This is what Patrick said last time this came up (source:
http://marc.info/?l=netfilter-devel&m=131471329004889&w=2 ):

"I don't think the clones should have invalid state, even untracked is
very questionable since all packets should have NAT applied to them in
the same way, connmarks might be used etc.

We probably need to restore the above mentioned assumption somehow. One
way would be to serialize reinjection of packets belonging to
unconfirmed conntracks in nf_reinject or the queueing modules. Conntrack
related stuff doesn't really belong there, but it seems like the easiest
and safest fix to me."

As for bridge conntrack, this is indeed a good question.

Seems we will need to register a dedicated conntrack bridge hook that
takes care of uncloning in FORWARD hook, i.e. add a hook in FORWARD
that makes a deep copy of all unconfirmed conntracks if skb is cloned,
and (once skb reaches nf_confirm) do a non-destructive clash resolution
(accept instead of drop of the clashing entries should be enough).

We have to sacrifice another status bit for this, or perhaps add a
bridge conntrack extension to store such a clash hint though.

Any other idea?

  reply	other threads:[~2016-09-02 10:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02  9:08 nfqueue & bridge netfilter considered broken Florian Westphal
2016-09-02  9:58 ` Pablo Neira Ayuso
2016-09-02 10:00   ` Pablo Neira Ayuso
2016-09-02 10:22     ` Florian Westphal [this message]
2016-09-06 10:10       ` Pablo Neira Ayuso
2016-09-06 11:24         ` 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=20160902102244.GB506@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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.