On Wed, May 28, 2025 at 9:41 PM Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, 28 May 2025, ying chen wrote: > > > On Wed, May 28, 2025 at 9:10 PM Florian Westphal <fw@xxxxxxxxx> wrote: > >> > >> ying chen <yc1082463@xxxxxxxxx> wrote: > >>> Hello all, > >>> > >>> I encountered an "nf_conntrack: table full" warning on Linux 6.15-rc4. > >>> Running cat /proc/net/nf_conntrack showed a large number of > >>> connections in the SYN_SENT state. > >>> As is well known, if we attempt to connect to a non-existent port, the > >>> system will respond with an RST and then delete the conntrack entry. > >>> However, when we frequently connect to non-existent ports, the > >>> conntrack entries are not deleted, eventually causing the nf_conntrack > >>> table to fill up. > >> > >> Yes, what do you expect to happen? > > I understand that the conntrack entry should be deleted immediately > > after receiving the RST reply. > > No, the conntrack entry will be in the CLOSE state with the timeout value > of /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close > > Best regards, > Jozsef The conntrack entry does not transition to the CLOSE state and remains in the SYN_SENT state until the nf_conntrack_tcp_timeout_syn_sent timeout is reached. According to the code, the conntrack entry should be deleted immediately after the RST reply. int nf_conntrack_tcp_packet(struct nf_conn *ct, struct sk_buff *skb, unsigned int dataoff, enum ip_conntrack_info ctinfo, const struct nf_hook_state *state) { ...... if (!test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) { /* If only reply is a RST, we can consider ourselves not to have an established connection: this is a fairly common problem case, so we can delete the conntrack immediately. --RR */ if (th->rst) { nf_ct_kill_acct(ct, ctinfo, skb); return NF_ACCEPT; }