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;
}
if (((test_bit(IPS_SEEN_REPLY_BIT, &ct->status)
&& ct->proto.tcp.last_index == TCP_SYN_SET)
Before I submit it, I'm wondering if you have any suggestion for this
issue and diff?
Thanks,
Chris
[1] netfilter: conntrack: tcp: only close if RST matches exact sequence
[2] netfilter: conntrack: add new sysctl to disable RST check
