On Tue, Feb 11, 2025 at 08:51:00PM +0100, Stefano Brivio wrote:This probably doesn't cover all the cases where we should send a zero-window probe, but it's rather unobtrusive and obvious, so start from here, also because I just observed this case (without the fix from the previous patch, to take into account window information from keep-alive segments). If we hit the ACK timeout, and try re-sending data from the socket, if the window is zero, we'll just fail again, go back to the timer, and so on, until we hit the maximum number of re-transmissions and reset the connection. Don't do that: forcibly try to send something by implementing the equivalent of a zero-window probe in this case. Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com>Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au>--- tcp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tcp.c b/tcp.c index 2addf4a..b87478f 100644 --- a/tcp.c +++ b/tcp.c @@ -2175,6 +2175,8 @@ void tcp_timer_handler(const struct ctx *c, union epoll_ref ref) flow_dbg(conn, "ACK timeout, retry"); conn->retrans++; conn->seq_to_tap = conn->seq_ack_from_tap; + if (!conn->wnd_from_tap) + conn->wnd_from_tap = 1; /* Zero-window probe */ if (tcp_set_peek_offset(conn->sock, 0)) { tcp_rst(c, conn); } else {-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson