[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251023144805.1979484-1-wokezhong@tencent.com>
Date: Thu, 23 Oct 2025 22:48:03 +0800
From: HaiYang Zhong <wokezhong@...il.com>
To: edumazet@...gle.com
Cc: ncardwell@...gle.com,
kuniyu@...gle.com,
davem@...emloft.net,
dsahern@...nel.org,
kuba@...nel.org,
pabeni@...hat.com,
horms@...nel.org,
netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
wokezhong@...cent.com
Subject: [PATCH v2 0/2] net/tcp: fix permanent FIN-WAIT-1 state and add packetdrill test
Hi Eric,
Thank you for your review and suggestions. As requested, I've added a packetdrill test to reproduce and verify the issue.
Changes in v2:
- Added packetdrill test in tools/testing/selftests/net/.
- The test reproduces the exact scenario described in the commit
message.
- Test verifies that the connection eventually times out after the fix.
The test covers:
1. TCP connection establishment.
2. Peer advertising zero window after receiving data.
3. Local close() with FIN blocked in send buffer.
4. Continuous zero window ACKs from peer.
5. Connection timeout verification.
About your question regarding the case where FIN was already sent but peer retracted RWIN:
In that scenario, peer will drop the FIN packet due to "TCPZeroWindowDrop". The FIN will be retransmitted by RTO, not by the zero-window probe timer.
I tested this with multiple kernel versions and the test reliably reproduces the issue before the fix and passes after the fix.
Thank you for your guidance!
Best regards,
HaiYang Zhong
HaiYang Zhong (2):
net/tcp: fix permanent FIN-WAIT-1 state with continuous zero window
packets
net/tcp: add packetdrill test for FIN-WAIT-1 zero-window fix
net/ipv4/tcp_input.c | 2 +
.../net/tcp_fin_wait1_zero_window.pkt | 58 +++++++++++++++++++
2 files changed, 60 insertions(+)
create mode 100644 tools/testing/selftests/net/tcp_fin_wait1_zero_window.pkt
--
2.43.7
Powered by blists - more mailing lists