aboutgitcodebugslistschat
path: root/icmp.c
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2023-09-08 11:49:53 +1000
committerStefano Brivio <sbrivio@redhat.com>2023-09-08 09:16:22 +0200
commit46f915ddee1bfd2514e2e6618d45452349d934cd (patch)
tree8243a4d42e8be282ab260f47c9b04d7c6574261d /icmp.c
parentb3f2210b05bc3c5057a6f2a197500df92eb7d71f (diff)
downloadpasst-46f915ddee1bfd2514e2e6618d45452349d934cd.tar
passt-46f915ddee1bfd2514e2e6618d45452349d934cd.tar.gz
passt-46f915ddee1bfd2514e2e6618d45452349d934cd.tar.bz2
passt-46f915ddee1bfd2514e2e6618d45452349d934cd.tar.lz
passt-46f915ddee1bfd2514e2e6618d45452349d934cd.tar.xz
passt-46f915ddee1bfd2514e2e6618d45452349d934cd.tar.zst
passt-46f915ddee1bfd2514e2e6618d45452349d934cd.zip
tcp: Correct handling of FIN,ACK followed by SYN
When the guest tries to establish a connection, it could give up on it by sending a FIN,ACK instead of a plain ACK to our SYN,ACK. It could then make a new attempt to establish a connection with the same addresses and ports with a new SYN. Although it's unlikely, it could send the 2nd SYN very shortly after the FIN,ACK resulting in both being received in the same batch of packets from the tap interface. Currently, we don't handle that correctly, when we receive a FIN,ACK on a not fully established connection we discard the remaining packets in the batch, and so will never process the 2nd SYN. Correct this by returning 1 from tcp_tap_handler() in this case, so we'll just consume the FIN,ACK and continue to process the rest of the batch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'icmp.c')
0 files changed, 0 insertions, 0 deletions