diff options
author | Stefano Brivio <sbrivio@redhat.com> | 2021-03-17 10:57:39 +0100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2021-03-17 10:57:39 +0100 |
commit | 4f675d63e8e32a2e8906953b71bd8210a9f82521 (patch) | |
tree | 4cf7820c233888220802b8b5d1ecc93d034710c9 /util.c | |
parent | a41894683710b00d67015cd1683eef6de0ffd89b (diff) | |
download | passt-4f675d63e8e32a2e8906953b71bd8210a9f82521.tar passt-4f675d63e8e32a2e8906953b71bd8210a9f82521.tar.gz passt-4f675d63e8e32a2e8906953b71bd8210a9f82521.tar.bz2 passt-4f675d63e8e32a2e8906953b71bd8210a9f82521.tar.lz passt-4f675d63e8e32a2e8906953b71bd8210a9f82521.tar.xz passt-4f675d63e8e32a2e8906953b71bd8210a9f82521.tar.zst passt-4f675d63e8e32a2e8906953b71bd8210a9f82521.zip |
tcp: Ignore out-of-order ACKs from tap instead of resetting connection
We might receive out-of-order ACK packets from the tap device, just
like any other packet.
I guess I've been overcautious and regarded it as a condition we
can't recover from, but all that happens is that we have already seen
a higher ACK sequence number, which means that data has been already
received and discarded from the buffer. We have to ignore the lower
sequence number we receive later, though, because that would force
the buffer bookkeeping into throwing away more data than expected.
Drop the ACK sequence assignment from tcp_tap_handler(), which was
redundant, and let tcp_sock_consume() take exclusive care of that.
Now that tcp_sock_consume() can never fail, make it a void, and
drop checks from callers.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'util.c')
0 files changed, 0 insertions, 0 deletions