This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Stalled download (TCP Previous segment not captured on trace)

0

Hi,

I'm having a tough time debugging a network issue. I'm downloading some files through HTTP/1.1 and, sometimes, i get stalled downloads after the client downloads some Kb.

I think that the server persistent connections logic is somehow buggy but it could also be caused by the client or how i am using it. However, i suspect it is a server issue because i don't get these problems with other servers but i get them with several clients (Erlang HTTP clients). Unfortunately i can't know which software is ran by the server.

In the attached capture i can see a connection (tcp.stream eq 3) that shows some errors until the client finally times out and closes it (first tried with FIN, then with RST).

https://www.cloudshark.org/captures/224e9e432f4c

What do these "TCP Previous segment not captured", retransmission and duplicated packets mean? What is happening? Can i blame the server?

PD: I have truncated the capture, both in number of packets (deleted pakcets after client RST) and in packet size (200 bytes) in order to upload it

asked 02 Oct '15, 06:42

alexvf's gravatar image

alexvf
11113
accept rate: 0%


One Answer:

0

"What do these "TCP Previous segment not captured", retransmission and duplicated packets mean?"
This is an indication of packet loss. If only this server is having the problem then the packet loss occurs close to this server.
The client is giving up after more than 14 seconds.

answered 05 Oct '15, 14:20

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

Is it compatible with the server dropping the connection (maybe a firewall DROP?) I would assume that if it were not by the packets arriving from server near the end of capture @ 21.99 ...

(06 Oct '15, 01:46) alexvf

The server is retransmitting with a very high RTO of more than 10s as seen at the client.

This indicates that also the retransmitted packets were dropped somewhere for a yet to be identified reason.

Neither the server nor a FW is dropping the connection though as it is the client that is sending a FIN to terminate

(06 Oct '15, 06:40) mrEEde

Thank you for the responses, mrEEde.

Yes, the client times out and closes the connection if it does not get X bytes in Y seconds (currently X = 100 Kb, Y = 15 s), which is enforced due to client application requirements. When the problem occurs, it usually downloads 30-70 Kb in those 15 seconds.

So i can only guess that both the client and the server are behaving right and someone in the middle is delaying the communication.

As i said, the client is under my control up to some limit but i know nothing about the server, let alone about the network. In this scenario, i would appreciate any advice that helps me debugging the problem.

(06 Oct '15, 11:24) alexvf

Unless you have access to somebody willing to support you at the server side you're pretty much at the end of your analysis. The problem is packet loss close to the server side that is causing timer based retransmissions which are delaying the TCP connection.

(07 Oct '15, 08:21) mrEEde