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@redhat.com>

Reviewed-by: David Gibson <david@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