On Wed, May 28, 2025 at 10:18 PM Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, 28 May 2025, ying chen wrote: > > > On Wed, May 28, 2025 at 9:45 PM Jozsef Kadlecsik > > <kadlec@xxxxxxxxxxxxxxxxx> wrote: > >> > >> On Wed, 28 May 2025, Eric Dumazet wrote: > >> > >>> On Wed, May 28, 2025 at 6:26 AM ying chen <yc1082463@xxxxxxxxx> 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. > >>> > >>> Then it probably hints that you do not receive RST for all your SYN > >>> packets. > >> > >> And Eric has got right: because the states are in SYN_SENT then either the > >> RST packets were not received or out of the window or invalid from other > >> reasons. > > I also suspect it's due to being "out of the window", but I'm not sure why. > > tcpdump of the traffic from the targeted machine with both the SYN and RST > packets could help (raw pcap or at least the output with absolute seqs). > > Best regards, > Jozsef Using bpftrace, I found that the RST is under the lower bound and printed the values of the following variables: receiver->td_maxwin = 1 sender->td_end = 0 receiver->td_maxwin =1
