aboutgitcodebugslistschat
path: root/util.c
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2021-03-17 10:57:39 +0100
committerStefano Brivio <sbrivio@redhat.com>2021-03-17 10:57:39 +0100
commit4f675d63e8e32a2e8906953b71bd8210a9f82521 (patch)
tree4cf7820c233888220802b8b5d1ecc93d034710c9 /util.c
parenta41894683710b00d67015cd1683eef6de0ffd89b (diff)
downloadpasst-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