aboutgitcodebugslistschat
path: root/contrib
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2024-03-26 16:42:24 +1100
committerStefano Brivio <sbrivio@redhat.com>2024-03-26 09:52:04 +0100
commit4988e2b406313c579836dc31867d793cfe77535c (patch)
tree811fbe1905875fd9a5f5a1fa76e8c91f7f71456e /contrib
parent5894a245b93f3c848c3a42d1c625eef3656b2eec (diff)
downloadpasst-4988e2b406313c579836dc31867d793cfe77535c.tar
passt-4988e2b406313c579836dc31867d793cfe77535c.tar.gz
passt-4988e2b406313c579836dc31867d793cfe77535c.tar.bz2
passt-4988e2b406313c579836dc31867d793cfe77535c.tar.lz
passt-4988e2b406313c579836dc31867d793cfe77535c.tar.xz
passt-4988e2b406313c579836dc31867d793cfe77535c.tar.zst
passt-4988e2b406313c579836dc31867d793cfe77535c.zip
tcp: Unconditionally force ACK for all !SYN, !RST packets2024_03_26.4988e2b
Currently we set ACK on flags packets only when the acknowledged byte pointer has advanced, or we hadn't previously set a window. This means in particular that we can send a window update with no ACK flag, which doesn't appear to be correct. RFC 9293 requires a receiver to ignore such a packet [0], and indeed it appears that every non-SYN, non-RST packet should have the ACK flag. The reason for the existing logic, rather than always forcing an ACK seems to be to avoid having the packet mistaken as a duplicate ACK which might trigger a fast retransmit. However, earlier tests in the function mean we won't reach here if we don't have either an advance in the ack pointer - which will already set the ACK flag, or a window update - which shouldn't trigger a fast retransmit. [0] https://www.ietf.org/rfc/rfc9293.html#section-3.10.7.4-2.5.2.1 Link: https://github.com/containers/podman/issues/22146 Link: https://bugs.passt.top/show_bug.cgi?id=84 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'contrib')
0 files changed, 0 insertions, 0 deletions