On 9/23/2024 6:03 PM, Florian Westphal wrote:
Chris Mi <cmi@xxxxxxxxxx> wrote:
Hi Pablo & Ali,
Our customer reported an issue. I found that it can be reproduced like
this. If the tcp client program sets socketopt linger to 0, when the client
program exits, RST packet will be sent instead of FIN.
But this RST packet doesn't match the expected sequence, server will
ignore it and the ct entry will be in ESTABLISHED state for 5 days.
It seems like an expected behavior due to commit [1].
We found another commit [2] in recent kernel. We tried to set
nf_conntrack_tcp_ignore_invalid_rst to 1.
It doesn't work as well. And the commit message is too short. We don't
know what's the usecase for it.
In our case, if we have the following diff, ct will be closed normally:
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c
b/net/netfilter/nf_conntrack_proto_tcp.c
index ae493599a3ef..04c0e5a86990 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -1218,7 +1218,8 @@ int nf_conntrack_tcp_packet(struct nf_conn *ct,
/* ... RST sequence number doesn't match exactly,
keep
* established state to allow a possible challenge
ACK.
*/
- new_state = old_state;
+ if (!tn->tcp_ignore_invalid_rst)
+ new_state = old_state;
Can you test if a call to
nf_tcp_handle_invalid() here resolves the problem as well?
Intent would be to reduce timeout but keep connecton state
as-is.
I don't think we should force customers to tweak sysctls to
make expiry work as intended.
It doesn't work. The if statement is not executed because the condition
is not met.
[Mon Sep 23 18:41:59 2024] nf_tcp_handle_invalid: 756, last_dir: 0, dir:
0, last_index: 3
Even if the if statement is executed, the timeout is still not changed.
