Re: ct hardware offload ignores RST packet

[Florian Westphal <fw@strlen.de>]

Chris Mi <cmi@nvidia.com> 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.