[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201009185552.GF5723@breakpoint.cc>
Date: Fri, 9 Oct 2020 20:55:52 +0200
From: Florian Westphal <fw@...len.de>
To: Jozsef Kadlecsik <kadlec@...filter.org>
Cc: Florian Westphal <fw@...len.de>,
Francesco Ruggeri <fruggeri@...sta.com>,
open list <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>, coreteam@...filter.org,
netfilter-devel@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
David Miller <davem@...emloft.net>, fw@...len.org,
Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [PATCH nf v2] netfilter: conntrack: connection timeout after
re-register
Jozsef Kadlecsik <kadlec@...filter.org> wrote:
> > 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).
>
> Sorry, I can't put together the two paragraphs above: in the first you
> wrote that no (hook) unregister-register happens and in the second one
> that those could be derefed.
Sorry, my reply is confusing indeed.
Matches/targets that need conntrack increment a refcount.
So, when all rules are flushed, refcount goes down to 0 and conntrack is
disabled because the hooks get removed..
Just doing iptables-restore doesn't unregister as long as both the old
and new rulesets need conntrack.
The "delay unregister" remark was wrt. the "all rules were deleted"
case, i.e. add a "grace period" rather than acting right away when
conntrack use count did hit 0.
> > We could disallow unregister, but that seems silly (forces reboot...).
> >
> > I think the patch is fine.
>
> The patch is fine, but why the packets are handled by conntrack (after the
> first restore and during the 4s sleep? And then again after the second
> restore?) as if all conntrack entries were removed?
Conntrack entries are not removed, only the base hooks get unregistered.
This is a problem for tcp window tracking.
When re-register occurs, kernel is supposed to switch the existing
entries to "loose" mode so window tracking won't flag packets as
invalid, but apparently this isn't enough to handle keepalive case.
Powered by blists - more mailing lists