diff options
| author | Stefano Brivio <sbrivio@redhat.com> | 2025-02-03 08:19:16 +0100 |
|---|---|---|
| committer | Stefano Brivio <sbrivio@redhat.com> | 2025-02-03 22:42:13 +0100 |
| commit | 722d347c1932f630a53ba05ea0270a651ed601b2 (patch) | |
| tree | 3fa3cb5704d35c32617d20ec7c7bce6301bca7e8 /util.c | |
| parent | bf2860819d868c7d116923e9b5d798d410d38715 (diff) | |
| download | passt-722d347c1932f630a53ba05ea0270a651ed601b2.tar passt-722d347c1932f630a53ba05ea0270a651ed601b2.tar.gz passt-722d347c1932f630a53ba05ea0270a651ed601b2.tar.bz2 passt-722d347c1932f630a53ba05ea0270a651ed601b2.tar.lz passt-722d347c1932f630a53ba05ea0270a651ed601b2.tar.xz passt-722d347c1932f630a53ba05ea0270a651ed601b2.tar.zst passt-722d347c1932f630a53ba05ea0270a651ed601b2.zip | |
tcp: Don't reset outbound connection on SYN retries
Reported by somebody on IRC: if the server has considerable latency,
it might happen that the client retries sending SYN segments for the
same flow while we're still in a TAP_SYN_RCVD, non-ESTABLISHED state.
In that case, we should go with the blanket assumption that we need
to reset the connection on any unexpected segment: RFC 9293 explicitly
mentions this case in Figure 8: Recovery from Old Duplicate SYN,
section 3.5. It doesn't make sense for us to set a specific sequence
number, socket-side, but we should definitely wait and see.
Ignoring the duplicate SYN segment should also be compatible with
section 3.10.7.3. SYN-SENT STATE, which mentions updating sequences
socket-side (which we can't do anyway), but certainly not reset the
connection.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'util.c')
0 files changed, 0 insertions, 0 deletions