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

TCP DUP ACK/TCP Retransmission

0
1

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's gravatar image

dmcmasters
6124
accept rate: 0%


3 Answers:

1

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's gravatar image

krishnayeddula
629354148
accept rate: 6%

edited 07 May '13, 20:13

1

You may filter out those DUPs from wireshark's display:

!_ws.expert.message == "Retransmission (suspected)" && !_ws.expert.message == "Duplicate ACK (#1)" && !_ws.expert.message == "Out-Of-Order segment"

Taken from http://thevisiblenetwork.com/2014/02/11/filter-duplicate-packets-from-a-capture-file/

answered 26 Sep '14, 01:22

cweiske's gravatar image

cweiske
264
accept rate: 0%

edited 16 Jan '17, 08:22

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))

(29 Sep '14, 13:33) DarrenWright

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"

(29 Sep '14, 14:00) mrEEde

0

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's gravatar image

Philst
4311616
accept rate: 27%

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