From: Florian Westphal <fw@strlen.de>
To: Matt Zagrabelny <mzagrabe@d.umn.edu>
Cc: Slavko <linux@slavino.sk>, netfilter <netfilter@vger.kernel.org>
Subject: Re: connection tracking and kernel dropping packets
Date: Sun, 10 Nov 2024 22:47:46 +0100 [thread overview]
Message-ID: <20241110214746.GA25943@breakpoint.cc> (raw)
In-Reply-To: <CAOLfK3UWDAOAww10O2NxFBPgLa+Rr92=Lw+qFb1fxDOhD_6Dgg@mail.gmail.com>
Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
> On Tue, Oct 29, 2024 at 10:48 AM Slavko <linux@slavino.sk> wrote:
> >
> > Dňa 29. októbra 2024 15:11:34 UTC používateľ Matt Zagrabelny <mzagrabe@d.umn.edu> napísal:
> >
> > >...but it is still dropping packets due to the CT.
> >
> > You have first to inspect what is filling your conntrack table:
> >
> > conntrack -L
>
> I've waited a week to let the TCP streams in the conntrack table time
> out. I'm still seeing the kernel drop packets:
conntrack -F not working?
> # tail -f /var/log/kern.log
> Nov 6 11:29:02 netadm kernel: [48773744.961053] nf_conntrack: table
> full, dropping packet.
>
> ...and confirmed with /proc:
>
> # cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
> 65536
>
> ...but there aren't that many flows in the conntrack table, and none
> in the expect table.
>
> # conntrack -L > /dev/null
> conntrack v1.2.1 (conntrack-tools): 22 flow entries have been shown.
Depending on userspace/kernel version this may only list ipv4.
> Any idea where to find what is still causing the kernel to drop packets?
>
> I still need to handle the INVALID state, but here is my current rule-set:
>
> # Generated by iptables-save v1.4.14 on Wed Nov 6 11:40:00 2024
> *raw
> :PREROUTING ACCEPT [559078817:46637850935]
> :OUTPUT ACCEPT [539455981:114717831525]
> [311121010:22258566347] -A PREROUTING -p udp -m udp --dport 53 -j CT --notrack
> [82158007:15791189816] -A PREROUTING -p udp -m udp --sport 53 -j CT --notrack
> [160638557:7854716900] -A PREROUTING -p tcp -m tcp --dport 53 -j CT --notrack
> [55174:13694242] -A PREROUTING -p tcp -m tcp --sport 53 -j CT --notrack
> [82898530:7187312985] -A OUTPUT -p udp -m udp --dport 53 -j CT --notrack
> [310815684:92319143568] -A OUTPUT -p udp -m udp --sport 53 -j CT --notrack
> [81356:4991618] -A OUTPUT -p tcp -m tcp --dport 53 -j CT --notrack
> [134221259:13321766219] -A OUTPUT -p tcp -m tcp --sport 53 -j CT --notrack
> COMMIT
Is this an ipv4 only system?
next prev parent reply other threads:[~2024-11-10 21:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 15:11 connection tracking and kernel dropping packets Matt Zagrabelny
2024-10-29 15:47 ` Slavko
2024-10-29 15:57 ` Matt Zagrabelny
2024-11-06 17:44 ` Matt Zagrabelny
2024-11-08 17:04 ` Slavko
2024-11-10 21:47 ` Florian Westphal [this message]
2024-11-11 19:14 ` Matt Zagrabelny
2024-10-29 16:11 ` Kerin Millar
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=20241110214746.GA25943@breakpoint.cc \
--to=fw@strlen.de \
--cc=linux@slavino.sk \
--cc=mzagrabe@d.umn.edu \
--cc=netfilter@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 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.