Revision history [back]

Can anyone point out any faults in this TCP capture at packet 556852, where the server at 172.31.251.9 is continuosly sending data at about 200 kbyte/s on port 62841 to the 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 :

https://drive.google.com/open?id=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

Can anyone point out any faults in this TCP capture at packet 556852, where the linux server at 172.31.251.9 is continuosly 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 :

https://drive.google.com/open?id=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

Can anyone point out any faults in this TCP capture at packet 556852, where the linux server at 172.31.251.9 is continuosly 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 :

https://drive.google.com/open?id=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz: large 200 mb capture : https://drive.google.com/open?id=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz small 8 mb capture : https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno 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, tore down the connection applicatively sending that FIN ? in my own experience overflowing the send buffer is recoverably by retrying after a delay, or polling for available send space in the socket buffer with select()

Can anyone point out any faults in this TCP capture at packet 556852, where the linux server at 172.31.251.9 is continuosly 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 : https://drive.google.com/open?id=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz https://drive.google.com/open?id=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

small 8 mb capture compressed with gzip : https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno

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, tore down the connection applicatively sending that FIN ? ?

in my own experience overflowing the send buffer is recoverably by retrying after a delay, or polling for available send space in the socket buffer with select()

Can anyone point out any faults in this TCP capture at packet 556852, where the linux server at 172.31.251.9 is continuosly 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 : https://drive.google.com/open?id=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

small 8 mb capture compressed with gzip : https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno

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, tore down the connection applicatively sending that FIN ?

in my own experience overflowing the send buffer is recoverably recoverable by retrying after a delay, or polling for available send space in the socket buffer with select()select(), without disrupting the TCP flow, i.e. there would be no faults observable in wireshark

Can anyone point out any faults in this TCP capture at packet 556852, capture, where the linux server at 172.31.251.9 is continuosly 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=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

small 8 mb capture compressed with gzip : FIN is at packet 6855: https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno

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, 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

Can anyone point out any faults in this TCP capture, where the linux server at 172.31.251.9 is continuosly 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=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

small 8 mb capture compressed with gzip FIN is at packet 6855: https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno

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, 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 wiresharkwireshark, could there be any evidence in wireshark of non blocking transmitter overflowing transmission buffer I wonder ?

Can anyone point out any faults in this TCP capture, where the linux server at 172.31.251.9 is continuosly 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=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

small 8 mb capture compressed with gzip FIN is at packet 6855: 6853: https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno

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, 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 ?

Can anyone point out any faults in this TCP capture, where the linux server at 172.31.251.9 is continuosly 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=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

small 8 mb capture compressed with gzip FIN is at packet 6853: https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno

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, 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 ?

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=1lGkPfHc2LsOZ3ChF5n40TGRrDVzW6vYz

small 8 mb capture compressed with gzip FIN is at packet 6853: https://drive.google.com/open?id=1T-Cc18mUgBnMwZLC0FbMWtVrdPU7dVno

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 ?