TCP previous segment not captured
Can anyone point out any faults in this TCP capture, where the linux server at 172.31.251.9 is continuously sending data at about 200 kbyte/s on port 62841 to the windows client at 10.88.101.23 and it has sent a FIN to close the connection, that I cannot understand if there are any faults either sending or receiving, thank you for any clues :
large 200 mb capture FIN is at packet 556852: https://drive.google.com/open?id=1lGk...
small 8 mb capture compressed with gzip FIN is at packet 6853: https://drive.google.com/open?id=1T-C...
could it be thinkable that the server is transmitting with a non blocking socket, in that moment it's transmit buffer overflowed i.e. the send returned EWOULDBLOCK, and instead of retrying the temporarily failed send, the server tore down the connection applicatively sending that FIN ?
in my own experience overflowing the send buffer is recoverable by retrying after a delay, or polling for available send space in the socket buffer with select(), without disrupting the TCP flow, i.e. there would be no faults observable in wireshark, could there be any evidence in wireshark of non blocking transmitter overflowing transmission buffer I wonder ?
For anyone trying to answer this question, be aware the provided link downloads a 215MB RAR archive. The PCAP is 435MB uncompressed and shows 1,121,662 packets. Fair warning.
I was already thrown off at "in this TCP capture at packet 556852" ;-)