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.....
Thanks a lot asked 08 May '17, 05:41 ValerioItaly |
One Answer:
The data you referencing (display filter 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 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 ♦ |
Is the link you provided an Excel spreadsheet? Can you instead provide a link to a packet capture file?
Sanitize your pcap if you need to: https://blog.packet-foo.com/2016/11/the-wireshark-qa-trace-file-sharing-tutorial/
Here you can find the capture : https://www.cloudshark.org/captures/f9c27db6a2aa
Thanks a lot
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?