aboutgitcodebugslistschat
path: root/dhcpv6.c
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2023-09-08 11:49:52 +1000
committerStefano Brivio <sbrivio@redhat.com>2023-09-08 09:16:19 +0200
commitb3f2210b05bc3c5057a6f2a197500df92eb7d71f (patch)
treecab65316df89b88d3e9751b8bcdef4852260dde6 /dhcpv6.c
parentf984003fdf2cc2dbd0ac55a47d9a4a25776fc2d0 (diff)
downloadpasst-b3f2210b05bc3c5057a6f2a197500df92eb7d71f.tar
passt-b3f2210b05bc3c5057a6f2a197500df92eb7d71f.tar.gz
passt-b3f2210b05bc3c5057a6f2a197500df92eb7d71f.tar.bz2
passt-b3f2210b05bc3c5057a6f2a197500df92eb7d71f.tar.lz
passt-b3f2210b05bc3c5057a6f2a197500df92eb7d71f.tar.xz
passt-b3f2210b05bc3c5057a6f2a197500df92eb7d71f.tar.zst
passt-b3f2210b05bc3c5057a6f2a197500df92eb7d71f.zip
tcp: Consolidate paths where we initiate reset on tap interface
There are a number of conditions where we will issue a TCP RST in response to something unexpected we received from the tap interface. These occur in both tcp_data_from_tap() and tcp_tap_handler(). In tcp_tap_handler() use a 'goto out of line' technique to consolidate all these paths into one place. For the tcp_data_from_tap() cases use a negative return code and direct that to the same path in tcp_tap_handler(), its caller. In this case we want to discard all remaining packets in the batch we have received: even if they're otherwise good, they'll be invalidated when the guest receives the RST we're sending. This is subtly different from the case where we *receive* an RST, where we could in theory get a new SYN immediately afterwards. Clarify that with a common on the now common reset path. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'dhcpv6.c')
0 files changed, 0 insertions, 0 deletions