diff options
author | Stefano Brivio <sbrivio@redhat.com> | 2025-02-11 20:19:05 +0100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2025-02-12 19:43:55 +0100 |
commit | 90f91fe72673e36c8e071a1750e9c03deb20ab0f (patch) | |
tree | 03a2b15e048a50b3cc6d9bbee18c6dc10c0156cc | |
parent | 472e2e930f6e17d9d8664d6cf44c47af1db58bb3 (diff) | |
download | passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.gz passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.bz2 passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.lz passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.xz passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.tar.zst passt-90f91fe72673e36c8e071a1750e9c03deb20ab0f.zip |
tcp: Implement conservative zero-window probe on ACK timeout
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>
-rw-r--r-- | tcp.c | 2 |
1 files changed, 2 insertions, 0 deletions
@@ -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 { |