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

Have the packets been ACKed or not ?

0

Hi, I'm troubleshooting a strange behaviour in an HTTP download.

I'm capturing (at the moment) just by client side. https://www.dropbox.com/s/q3bxhxos55j1cv0/Test_1_Client_view_1.0.xlsx?dl=0

In the following days I will do the same in several points in the path and on the server too.

But now I need to explain this:

Client receives 307 Spurious Retransmission from Server. It means that it has received also the original 307 packets.

I know that a cause of these 307 Retransmissions done by the server towards the client could be that the server did not receive the ACK from client.

Before moving to have a look at the capture in the path and on the server, my questions are :

In the capture taken on client.....

  • Did the client acknowledge the original 307 packets coming from the server ?

  • For example, the first SEQ 3996984356 coming from the Server, in which ACK packet has been acknowledged by the client ?

  • How do you discover it ?

Thanks a lot

asked 08 May '17, 05:41

ValerioItaly's gravatar image

ValerioItaly
5334
accept rate: 0%

Is the link you provided an Excel spreadsheet? Can you instead provide a link to a packet capture file?

(08 May '17, 08:00) cmaynard ♦♦
(08 May '17, 08:52) Jasper ♦♦

Here you can find the capture : https://www.cloudshark.org/captures/f9c27db6a2aa

Thanks a lot

(08 May '17, 13:42) ValerioItaly

Hi, about what kind of environment do we talk? I can see a round trip time of (iRTT) of 22 ms. Is there a WAN link in the path?

(09 May '17, 13:22) Christian_R

One Answer:

1

The data you referencing (display filter tcp.seq == 3996984356) gets transmitted by the server (for the the first time ) in frame 4655 (frame.number==4655). Then there is a spurious retransmit in frame 5634 for this data..

It's spurious because the client already acknowledges the data with a Selective ACK in frame 4656 (so right after receiving the first transmit).

Site note: The SACK option can only handle five ranges (due to max size of TCP header). However in your capture it's seems there is more packet loss. Therefore the ranges shifts during the data transfer.

answered 09 May '17, 00:57

Uli's gravatar image

Uli
9031515
accept rate: 29%

Hi Uli, thanks a lot for your help.

Very useful to know the "Site Note" about the Max couples of SLE/SRE that can be displayed.

Could you kindly help me to understand how can you notice that in the SLE/SRE info of the packet 4656, there is the ACK of the packet 4655 ?

(09 May '17, 01:40) ValerioItaly

Frame 4655 has a SEQ#3996984356, TCP data length is 1380 Bytes => tcp.nxtseq == 3996985736.

Frame 4656 ACKs 3995738216 and additional the SACK for ranges 3996982976-3996985736, 3996920876-3996981596, 3996862916-3996919496 and 3996798056-3996861536.

This means the client has received among others the bytes 3996982976-3996985736 => Data which was transmitted in frame 4655 (and some other frames before).

(09 May '17, 02:47) Uli

Thanks a lot !!

(10 May '17, 05:44) ValerioItaly

If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.

(10 May '17, 05:46) grahamb ♦