From: Florian Westphal <fw@strlen.de>
To: Jozsef Kadlecsik <kadlec@netfilter.org>
Cc: Francesco Ruggeri <fruggeri@arista.com>,
open list <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
coreteam@netfilter.org, netfilter-devel@vger.kernel.org,
Jakub Kicinski <kuba@kernel.org>,
David Miller <davem@davemloft.net>,
fw@strlen.org, Pablo Neira Ayuso <pablo@netfilter.org>
Subject: Re: [PATCH nf v2] netfilter: conntrack: connection timeout after re-register
Date: Fri, 9 Oct 2020 13:03:23 +0200 [thread overview]
Message-ID: <20201009110323.GC5723@breakpoint.cc> (raw)
In-Reply-To: <alpine.DEB.2.23.453.2010090838430.19307@blackhole.kfki.hu>
Jozsef Kadlecsik <kadlec@netfilter.org> wrote:
> > Any comments?
> > Here is a simple reproducer. The idea is to show that keepalive packets
> > in an idle tcp connection will be dropped (and the connection will time
> > out) if conntrack hooks are de-registered and then re-registered. The
> > reproducer has two files. client_server.py creates both ends of a tcp
> > connection, bounces a few packets back and forth, and then blocks on a
> > recv on the client side. The client's keepalive is configured to time
> > out in 20 seconds. This connection should not time out. test is a bash
> > script that creates a net namespace where it sets iptables rules for the
> > connection, starts client_server.py, and then clears and restores the
> > iptables rules (which causes conntrack hooks to be de-registered and
> > re-registered).
>
> In my opinion an iptables restore should not cause conntrack hooks to be
> de-registered and re-registered, because important TCP initialization
> parameters cannot be "restored" later from the packets. Therefore the
> proper fix would be to prevent it to happen. Otherwise your patch looks OK
> to handle the case when conntrack is intentionally restarted.
The repro clears all rules, waits 4 seconds, then restores the ruleset.
using iptables-restore < FOO; sleep 4; iptables-restore < FOO will
not result in any unregister ops.
We could make kernel defer unregister via some work queue but i don't
see what this would help/accomplish (and its questionable of how long it
should wait).
We could disallow unregister, but that seems silly (forces reboot...).
I think the patch is fine.
next prev parent reply other threads:[~2020-10-09 11:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 19:32 [PATCH nf v2] netfilter: conntrack: connection timeout after re-register Francesco Ruggeri
2020-10-08 23:41 ` Francesco Ruggeri
2020-10-09 6:52 ` Jozsef Kadlecsik
2020-10-09 11:03 ` Florian Westphal [this message]
2020-10-09 18:48 ` Jozsef Kadlecsik
2020-10-09 18:55 ` Florian Westphal
2020-10-09 19:49 ` Jozsef Kadlecsik
2020-10-09 20:00 ` Francesco Ruggeri
2020-10-09 20:05 ` Florian Westphal
2020-10-14 0:06 ` Pablo Neira Ayuso
2020-10-14 8:11 ` Pablo Neira Ayuso
2020-10-14 8:23 ` Florian Westphal
2020-10-14 18:42 ` Francesco Ruggeri
2020-10-14 19:35 ` Florian Westphal
2020-10-20 15:21 ` Pablo Neira Ayuso
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=20201009110323.GC5723@breakpoint.cc \
--to=fw@strlen.de \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=fruggeri@arista.com \
--cc=fw@strlen.org \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--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.