From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Sven Auhagen <sven.auhagen@voleatech.de>
Cc: netfilter-devel@vger.kernel.org, cratiu@nvidia.com,
ozsh@nvidia.com, vladbu@nvidia.com, gal@nvidia.com, fw@strlen.de
Subject: Re: [PATCH nf] netfilter: flowtable: infer TCP state and timeout before flow teardown
Date: Tue, 9 Apr 2024 13:11:43 +0200 [thread overview]
Message-ID: <ZhUibxdb005sYZNq@calendula> (raw)
In-Reply-To: <x3qvcfxgdmurfnydhrs7ao6fmxxubmhxs2mjk24yn5zjfbo3h5@esbr3eff7bir>
Hi Sven,
On Mon, Apr 08, 2024 at 07:24:43AM +0200, Sven Auhagen wrote:
> Hi Pablo,
>
> after some testing the problem only happens very rarely now.
> I suspect it happens only on connections that are at some point
> one way only or in some other way not in a correct state anymore.
> Never the less your latest patches are very good and reduce the problem
> to an absolute minimum that FIN WAIT is offlodaded and the timeout
> is correct now.
Thanks for testing, I am going to submit this patch.
If you have a bit more cycles, I still would like to know what corner
case scenario is still triggering this so...
> Here is one example if a flow that still is in FIN WAIT:
>
> [NEW] tcp 6 120 SYN_SENT src=fd00::192:168:5:32 dst=2a05:d014:687:ed01::21 sport=58790 dport=443 [UNREPLIED] src=2a05:d014:687:ed01::21 dst=2003:a:c7f:e5e8:a3ae:63f7:7f92:e286 sport=443 dport=60848 mark=16777216
> [UPDATE] tcp 6 60 SYN_RECV src=fd00::192:168:5:32 dst=2a05:d014:687:ed01::21 sport=58790 dport=443 src=2a05:d014:687:ed01::21 dst=2003:a:c7f:e5e8:a3ae:63f7:7f92:e286 sport=443 dport=60848 mark=16777216
> [UPDATE] tcp 6 86400 ESTABLISHED src=fd00::192:168:5:32 dst=2a05:d014:687:ed01::21 sport=58790 dport=443 src=2a05:d014:687:ed01::21 dst=2003:a:c7f:e5e8:a3ae:63f7:7f92:e286 sport=443 dport=60848 [OFFLOAD] mark=16777216
> [UPDATE] tcp 6 120 FIN_WAIT src=fd00::192:168:5:32 dst=2a05:d014:687:ed01::21 sport=58790 dport=443 src=2a05:d014:687:ed01::21 dst=2003:a:c7f:e5e8:a3ae:63f7:7f92:e286 sport=443 dport=60848 [OFFLOAD] mark=16777216
> [UPDATE] tcp 6 30 LAST_ACK src=fd00::192:168:5:32 dst=2a05:d014:687:ed01::21 sport=58790 dport=443 src=2a05:d014:687:ed01::21 dst=2003:a:c7f:e5e8:a3ae:63f7:7f92:e286 sport=443 dport=60848 [ASSURED] mark=16777216
> [UPDATE] tcp 6 120 TIME_WAIT src=fd00::192:168:5:32 dst=2a05:d014:687:ed01::21 sport=58790 dport=443 src=2a05:d014:687:ed01::21 dst=2003:a:c7f:e5e8:a3ae:63f7:7f92:e286 sport=443 dport=60848 [ASSURED] mark=16777216
> [DESTROY] tcp 6 TIME_WAIT src=fd00::192:168:5:32 dst=2a05:d014:687:ed01::21 sport=58790 dport=443 packets=15 bytes=1750 src=2a05:d014:687:ed01::21 dst=2003:a:c7f:e5e8:a3ae:63f7:7f92:e286 sport=443 dport=60848 packets=13 bytes=6905 [ASSURED] mark=16777216 delta-time=120
... could you run conntrack -E -o timestamp? I'd like to know if this is
a flow that is handed over back to classic path after 30 seconds, then
being placed in the flowtable again.
next prev parent reply other threads:[~2024-04-09 11:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 9:39 [PATCH nf] netfilter: flowtable: infer TCP state and timeout before flow teardown Pablo Neira Ayuso
2024-03-18 10:05 ` Sven Auhagen
2024-03-20 8:39 ` Sven Auhagen
2024-03-20 8:45 ` Pablo Neira Ayuso
2024-03-20 8:49 ` Sven Auhagen
2024-03-20 9:07 ` Pablo Neira Ayuso
2024-03-20 9:20 ` Sven Auhagen
2024-03-20 9:27 ` Pablo Neira Ayuso
2024-03-20 9:31 ` Sven Auhagen
2024-03-20 9:51 ` Pablo Neira Ayuso
2024-03-20 10:13 ` Sven Auhagen
2024-03-20 10:36 ` Pablo Neira Ayuso
2024-03-20 10:38 ` Sven Auhagen
2024-03-20 10:29 ` Sven Auhagen
2024-03-20 10:47 ` Pablo Neira Ayuso
2024-03-20 11:15 ` Sven Auhagen
2024-03-20 12:37 ` Pablo Neira Ayuso
2024-03-20 13:37 ` Sven Auhagen
2024-04-08 5:24 ` Sven Auhagen
2024-04-09 11:11 ` Pablo Neira Ayuso [this message]
2024-04-09 11:35 ` Sven Auhagen
2024-04-11 9:27 ` Pablo Neira Ayuso
2024-04-11 11:05 ` Florian Westphal
2024-04-11 11:40 ` Pablo Neira Ayuso
2024-04-11 12:13 ` Florian Westphal
2024-04-11 15:50 ` Pablo Neira Ayuso
2024-04-19 7:47 ` Sven Auhagen
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=ZhUibxdb005sYZNq@calendula \
--to=pablo@netfilter.org \
--cc=cratiu@nvidia.com \
--cc=fw@strlen.de \
--cc=gal@nvidia.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=ozsh@nvidia.com \
--cc=sven.auhagen@voleatech.de \
--cc=vladbu@nvidia.com \
/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.