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