I did some orginal captures on a computer sitting outside our firewall and saw alot of TCP DUP ACK/TCP Retransmission while web browsing. Thought I was having an ISP issue but their testing is indicating no trouble. I thought this message indicated dropped frames. Am I incorrect? I did another capture between two computers on a 24 port switch, no Internet, no connection other than to each other. One computer coping data from the second and the third doing the capture. I still see this messages. This capture is me going to Foxnews https://www.cloudshark.org/captures/81fc503552a8 Can someone explain is this normal? Thanks asked 07 May '13, 10:46  dmcmasters |
3 Answers:
TCP has this inherent mechanism of recovery. In tcp stream eq 8 of your trace there was a condition of retransmission generated due to timing but not because of drops. Here is the snippet of your trace. Step-1)Server send a packet to client(Let us call it packet-A){Packet.no-150} Step-2)Client acknowledged the packet (Let us call it ack-A){Packet.no-192} Step-3)Somehow packet-A was retransmitted by Server.The reason might be the delay in receiving ack-A from client and ack timer got out and retransmission timer got kicked in.(Dup of Packet-A){Packet.no-194} Step-4)Client generated a duplicate ack for the retransmitted packet.(Dup of ack-A){Packet.no-195} It is not always implies to losses whenever you see these retransmissions and duplicate acks.How timers got implemented also plays a role. With that said leaving to expert opinions.... answered 07 May '13, 17:33  krishnayeddula edited 07 May '13, 20:13 |
You may filter out those DUPs from wireshark's display: Taken from http://thevisiblenetwork.com/2014/02/11/filter-duplicate-packets-from-a-capture-file/ answered 26 Sep '14, 01:22  cweiske edited 16 Jan '17, 08:22 |
I realise that this is a very old question, so the answer is probably too late for the original poster - but may be of interest to anyone finding this post now. Packet #149 ACKs everything up to packet #148 data. #150 is the last packet of the burst and isn't ACKed because the receiver sends an ACK only for every two packets (normal behaviour). Both sides now timeout after around 200ms. The receiver sends a Delayed ACK (#192 - an ACK to #150) and almost at the same time receives #194 (a retransmission of #150 - sent after a Retransmission Timeout at the sender). In response to the unnecessary "spurious" retransmission (#194), the receiver sends a Duplicate-SACK (D-SACK, #195). A D-SACK is the use of the SACK mechanism to inform the sender that it has sent duplicate data (#194 = #150). Note the "Left Edge = 23361 & Right Edge = 24062" in the TCP Options/SACK detail. D-SACKs are also Dup-ACKs. The next action in this connection Is another GET after around 1 second. This one second delay is purely due to the client. We paid a "cost" of 200ms because the server's burst had an odd number of packets. answered 05 Dec '16, 19:57  Philst There are other occurrences of the same behaviour in this capture. One is: Packets #970, #979, #980 and #981. (05 Dec '16, 20:39) Philst |
Couldn't get your filter working. This one worked for me though:
!tcp.analysis.out_of_order && ((!tcp.analysis.duplicate_ack_num == 1) || (!tcp.analysis.duplicate_ack_num == 2))
The latest release(s) changed the expert. field names to _ws.expert.. So the filter above will still work when it is corrected using the new syntax:
!_ws.expert.message == "Retransmission (suspected)" && !_ws.expert.message == "Duplicate ACK (#1)" && !_ws.expert.message == "Out-Of-Order segment"