aboutgitcodebugslistschat
path: root/contrib
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2025-02-13 16:24:55 +0100
committerStefano Brivio <sbrivio@redhat.com>2025-02-14 10:04:39 +0100
commit30f1e082c3c0cee0a985b3c32e2b05280c596343 (patch)
tree8cb99db75a64fd14c80b5df401758c82bec4f7fa /contrib
parent98d474c8950e9cc5715d5686614fb0f504377303 (diff)
downloadpasst-30f1e082c3c0cee0a985b3c32e2b05280c596343.tar
passt-30f1e082c3c0cee0a985b3c32e2b05280c596343.tar.gz
passt-30f1e082c3c0cee0a985b3c32e2b05280c596343.tar.bz2
passt-30f1e082c3c0cee0a985b3c32e2b05280c596343.tar.lz
passt-30f1e082c3c0cee0a985b3c32e2b05280c596343.tar.xz
passt-30f1e082c3c0cee0a985b3c32e2b05280c596343.tar.zst
passt-30f1e082c3c0cee0a985b3c32e2b05280c596343.zip
tcp: Keep updating window and checking for socket data after FIN from guest
Once we get a FIN segment from the container/guest, we enter something resembling CLOSE_WAIT (from the perspective of the peer), but that doesn't mean that we should stop processing window updates from the guest and checking for socket data if the guest acknowledges something. If we don't do that, we can very easily run into a situation where we send a burst of data to the tap, get a zero window update, along with a FIN segment, because the flow is meant to be unidirectional, and now the connection will be stuck forever, because we'll ignore updates. Reproducer, server: $ pasta --config-net -t 9999 -- sh -c 'echo DONE | socat TCP-LISTEN:9997,shut-down STDIO' and client: $ ./test/rampstream send 50000 | socat -u STDIN TCP:$LOCAL_ADDR:9997 2025/02/13 09:14:45 socat[2997126] E write(5, 0x55f5dbf47000, 8192): Broken pipe while at it, update the message string for the third passive close state (which we see in this case): it's CLOSE_WAIT, not LAST_ACK. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'contrib')
0 files changed, 0 insertions, 0 deletions