diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2024-03-26 16:42:24 +1100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2024-03-26 09:52:04 +0100 |
commit | 4988e2b406313c579836dc31867d793cfe77535c (patch) | |
tree | 811fbe1905875fd9a5f5a1fa76e8c91f7f71456e /contrib | |
parent | 5894a245b93f3c848c3a42d1c625eef3656b2eec (diff) | |
download | passt-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