TCP high concurrency, RST connection cannot be released normally

TCP high concurrency, RST connection cannot be released normally

[Oracle]

[-- Attachment #1.1: Type: text/plain, Size: 2203 bytes --]

  Problem description: Abnormal message appears in high-concurrency short connection, the server sends rst to the client, the client connection is closed, but the server connection that sends rst is still in ESTABLISHED state? What is the reason?
I captured some information through bpf and confirmed that the server sent rst and the client status changed to close. I tracked the failure return of tcp_v4_send_reset and tcp_rcv_state_process and found that TCP RST: ACK flag = 1, but the tcp state printed here is the listen state, which is not consistent with the current connection status viewed by netstat. (Not sure if some events are discarded), but the tcpdump packet capture analysis shows that the server is indeed rst and the connection is not released.



[root@systest104 zx]# netstat -atpn|grep 45129 |grep ES
tcp        0      0 10.13.8.104:45129       10.13.8.104:45052       ESTABLISHED 3942077/postgres:  #The connection still exists



tcpdump:
02:58:06.494295 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    10.13.8.104.45129 > 10.13.8.104.45052: Flags [S.], cksum 0x2518 (incorrect -> 0x7ac8), seq 214961739, ack 2894898555, win 65535, options [mss 65495,sackOK,TS val 1670384838 ecr 1670384838,nop,wscale 11], length 0

02:58:06.496318 IP (tos 0x0, ttl 64, id 15240, offset 0, flags [DF], proto TCP (6), length 52)
    10.13.8.104.45052 > 10.13.8.104.45129: Flags [.], cksum 0x2510 (incorrect -> 0xa39b), seq 65579, ack 39408264, win 32, options [nop,nop,TS val 1670384839 ecr 1670384838], length 0
02:58:06.496321 IP (tos 0x0, ttl 64, id 15241, offset 0, flags [DF], proto TCP (6), length 84)
    10.13.8.104.45052 > 10.13.8.104.45129: Flags [P.], cksum 0x2530 (incorrect -> 0x2b50), seq 65579:65611, ack 39408264, win 32, options [nop,nop,TS val 1670384839 ecr 1670384838], length 32

02:58:06.497830 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.13.8.104.45129 > 10.13.8.104.45052: Flags [R], cksum 0x0f95 (correct), seq 214961740, win 0, length 0

[-- Attachment #1.2: Type: text/html, Size: 2551 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: TCP high concurrency, RST connection cannot be released normally

[Siddh Raman Pant]

On Sat, 31 May 2025 14:02:08 +0530, oraclelinux@foxmail.com wrote:
> Problem description: Abnormal message appears in high-concurrency
> short connection, the server sends rst to the client, the client
> connection is closed, but the server connection that sends rst is
> still in ESTABLISHED state? What is the reason?
> I captured some information through bpf and confirmed that the
> server sent rst and the client status changed to close. I tracked
> the failure return of tcp_v4_send_reset and tcp_rcv_state_process
> and found that TCP RST: ACK flag = 1, but the tcp state printed here
> is the listen state, which is not consistent with the current
> connection status viewed by netstat. (Not sure if some events are
> discarded), but the tcpdump packet capture analysis shows that the
> server is indeed rst and the connection is not released.

Please mention the kernel version and userspace / distro used. While I
do not know how to fix it, a more complete picture would make the task
easier for someone who knows (and the guy reading this 8 years later).

Does the same happen on another system with same / different versions?
Worth a shot if you have a reproducer.

Thanks,
Siddh

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: TCP high concurrency, RST connection cannot be released normally

[Siddh Raman Pant]

Please use plain text email instead of HTML and reply to the original
email again.

Your email was likely rejected / filtered as spam by the mailing list,
maybe because of the image.

Also:
https://docs.kernel.org/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions

Thanks,
Siddh

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies