Re: ct hardware offload ignores RST packet

[Chris Mi <cmi@nvidia.com>]

On 9/23/2024 6:03 PM, Florian Westphal wrote:
> 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.

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.