TCP previous segment not captured

asked 2019-08-22 13:49:11 +0000

berserk
1 ●1 ●1 ●2

updated 2019-08-23 15:39:54 +0000

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 ?

edit retag flag offensive close merge delete

Comments

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.

Spooky ( 2019-08-23 01:56:53 +0000 )edit

I was already thrown off at "in this TCP capture at packet 556852" ;-)

SYN-bit ( 2019-08-23 07:33:14 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-08-23 02:54:21 +0000

Spooky

191 ●47 ●7 https://www.wireshark.org

Hi Berserk,

First of all, when you save a large capture you can check "compress with gzip" to automatically compress the PCAP.

Wireshark can automatically open file compressed this way so there is no need to use WinRAR, WinZIP, 7-ZIP, etc.

Secondly, try to capture TCP connections from the start so you have all 3-way handshake TCP segments for SYN, SYN/ACK and ACK. These segment provide lots of information.

Now as far as I can tell, the "TCP previous segment not captured" you are seeing are because of packet loss. This is why there are Duplicate ACKs while the server retransmit the missing segments.

The TCP FIN segment is a proper way to terminate a TCP connection. The fact that you are seeing means host 172.31.251.9 wants to close this TCP connection. The 4-way handshake FIN/ACK, ACK, FIN/ACK, ACK means this TCP connection was properly closed by both client and server. It does not mean there is a network problem.

Now if this is unexpected then you need to find out why host 172.31.251.9 decided it was time to close the connection. This may be due to a resource issue or more likely an OS or software parameter/trigger.

Hope this helps.

Cheers,

JFD

edit flag offensive delete link

Comments

Hi I updated my post above that I suspect the server is overflowing it's send buffer, since I have no means to "audit" either it's configuration or source code I was wondering if any clues might be from wireshark, my suspicion is that it's impossible to detect send truncation from wireshark, it would just show up as "previous segment not captured" ...

I suspect the server is not retrying such as for example :

int SendBytes(SOCKET    sock, char *bytes, unsigned int bytesToSend)
{

    int sent = 0;
    while (bytesToSend > sent)
    {
        int nsent = send(sock, bytes + sent, bytesToSend - sent, 0);

        if ((nsent == SOCKET_ERROR) || (nsent < 0))
        {
            int lasterr = GetLastError();
            if (lasterr == WSAEWOULDBLOCK)
                continue;// this is not a real send error with non blocking socket
            int werr = WSAGetLastError();
            if (werr == WSAEWOULDBLOCK)
                continue;// this is not a real send error with non blocking socket

            std::string log;// an actual real error
            log ...

(more)

berserk ( 2019-08-23 09:55:24 +0000 )edit

add a comment

answered 2019-08-23 10:55:54 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

In the small capture file I see some packet-loss and recovery. But at the time of the FIN, there is no packet-loss. There are full-size frames, but that happens at other times too. So from the capture point-of-view, it is just the sending system closing the connection for whatever reason. As you have made the trace on the receiving end, it could be worthwhile to also look at a trace on the sending side.

Normally I would expect a FIN to be generated by the application (if TCP wants to close the connection because of problems, it uses a RST). So I assume this problem to be a problem in the sending application and you would need logging and/or debugging in the application to pinpoint the source of it closing the connection. If the application development is nut under your control, I would suggest to open a case with the application developer.

edit flag offensive delete link

Comments

that's it, I would expect to find an ACK RST sent by the receiver indicating a problem on the receiver, I can only suspect something wrong in the transmitter, which I cannot access

berserk ( 2019-08-23 11:05:17 +0000 )edit

If the transmitter is not under your control, capture at the demarcation point and if you receive the data packet with the FIN bit set there too, then it is out of your control and you need to hand it over to the sending side to solve.

SYN-bit ( 2019-08-23 11:39:52 +0000 )edit

add a comment