Starting from Linux kernel commit 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks"), window limits are enforced more aggressively with a bigger amount of zero-window updates compared to what happened with e2142825c120 ("net: tcp: send zero-window ACK when no memory") alone, and occasional duplicate ACKs can now be seen also for local transfers with default (208 KiB) socket buffer sizes.
Paul reports that, with 6.17-rc1-ish kernels, Podman tests for the pasta integration occasionally fail on the "TCP/IPv4 large transfer, tap" case.
While playing with a reproducer that seems to be matching those failures:
while true; do ./pasta --trace -l /tmp/pasta.log -p /tmp/pasta.pcap --config-net -t 5555 -- socat TCP-LISTEN:5555 OPEN:/tmp/large.rcv,trunc & (sleep 0.3; socat -T2 OPEN:large.bin TCP:88.198.0.164:5555; ); wait; diff large.bin /tmp/large.rcv || break; done
and a kernel including that commit, I hit a few different failures, that should be fixed by this series.
Stefano Brivio (6): tcp: FIN flags have to be retransmitted as well tcp: Factor sequence rewind for retransmissions into a new function tcp: Rewind sequence when guest shrinks window to zero tcp: Fix closing logic for half-closed connections tcp: Don't try to transmit right after the peer shrank the window to zero tcp: Fast re-transmit if half-closed, make TAP_FIN_RCVD path consistent
tcp.c | 170 ++++++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 118 insertions(+), 52 deletions(-) I applied the series in my test VM and run the reproducer from the
Hi, On 15/08/2025 18:10, Stefano Brivio wrote: podman tests where I noticed the flake. It failed after about 10mins and then when I enabled pasta trace logs and tcpdump captures then it took 208 mins for me to reproduce so it doesn't seem to fix the issue I am seeing. I did send the pasta log/pcap files in private to Stefano for further debugging. -- Paul Holzinger