From: Florian Westphal <fw@strlen.de>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org
Subject: Re: 6.1: possible bug with netfilter conntrack?
Date: Fri, 13 Jan 2023 00:38:08 +0100 [thread overview]
Message-ID: <20230112233808.GA19463@breakpoint.cc> (raw)
In-Reply-To: <Y8CR3CvOIAa6QIZ4@shell.armlinux.org.uk>
Russell King (Oracle) <linux@armlinux.org.uk> wrote:
> Hi,
>
> I've noticed that my network at home is rather struggling, and having
> done some investigation, I find that the router VM is dropping packets
> due to lots of:
>
> nf_conntrack: nf_conntrack: table full, dropping packet
>
> I find that there are about 2380 established and assured connections
> with a destination of my incoming mail server with destination port 25,
> and 2 packets. In the reverse direction, apparently only one packet was
> sent according to conntrack. E.g.:
>
> tcp 6 340593 ESTABLISHED src=180.173.2.183 dst=78.32.30.218
> sport=49694 dport=25 packets=2 bytes=92 src=78.32.30.218
> dst=180.173.2.183 sport=25 dport=49694 packets=1 bytes=44 [ASSURED]
> use=1
Non-early-evictable entry that will expire in ~4 days, so not really
surprising that this eventually fills the table.
I'd suggest to reduce the
net.netfilter.nf_conntrack_tcp_timeout_established
sysctl to something more sane, e.g. 2 minutes or so unless you need
to have longer timeouts.
But this did not change, so not the root cause of this problem.
> However, if I look at the incoming mail server, its kernel believes
> there are no incoming port 25 connetions, which matches exim.
>
> I hadn't noticed any issues prior to upgrading from 5.16 to 6.1 on the
> router VM, and the firewall rules have been the same for much of
> 2021/2022.
>
> Is this is known issue? Something changed between 5.16 and 6.1 in the
> way conntrack works?
Nothing that should have such an impact.
Does 'sysctl net.netfilter.nf_conntrack_tcp_loose=0' avoid the buildup
of such entries? I'm wondering if conntrack misses the connection
shutdown or if its perhaps triggering the entries because of late
packets or similar.
If that doesn't help. you could also check if
'sysctl net.netfilter.nf_conntrack_tcp_be_liberal=1' helps -- if it
does, its time for more debugging but its too early to start digging
atm. This would point at conntrack ignoring/discarding fin/reset
packets.
next prev parent reply other threads:[~2023-01-12 23:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 23:03 6.1: possible bug with netfilter conntrack? Russell King (Oracle)
2023-01-12 23:38 ` Florian Westphal [this message]
2023-01-13 0:16 ` Russell King (Oracle)
2023-01-12 23:40 ` Russell King (Oracle)
2023-01-12 23:45 ` Florian Westphal
2023-01-13 11:12 ` Russell King (Oracle)
2023-01-13 12:56 ` Florian Westphal
2023-01-13 13:36 ` Russell King (Oracle)
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=20230112233808.GA19463@breakpoint.cc \
--to=fw@strlen.de \
--cc=coreteam@netfilter.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).