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.
