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

Help, I do not understand what I am seeing


I have a NAS that is running slow, has been. When I run Wireshark while opening a file on that appliance I am seeing lots and lots of the examples below. (To me it looks like way to many)

90[TCP Dup ACK 8796#16] 6873>microsoft-ds [ACK] seq=27065 Ack=8756344 Win=1619 Len=0 SRE=8824884 SLE=88161

1514 [TCP segment of a reasembled PDU]

asked 21 Mar '13, 11:14

freebird317's gravatar image

accept rate: 0%

3 Answers:


Hard to tell without more details, but Dup ACKs are acknowledgements that were repeated (in this example 16 times, so a total of 17 identical acknowledges). This is usually a sign of either lost packets or impatient receiving nodes. Problem with NAS captures is that they get pretty big, but you could try to look for packet loss, retransmissions or zero window problems. There is a combo filter that will show you issues like that: tcp.analysis.flags.

answered 21 Mar '13, 11:28

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%


Duplicate acknowledgements gets triggered when there is a packet loss. It is the client/receiver's way of notifying the server/sender that "hey i some how lost a segment can you please retransmit again"In normal case server pay attention to these duplicate acks and sends a retransmission to the client. You can set the display filter as tcp.analysis.flags to dig further.

answered 21 Mar '13, 11:26

krishnayeddula's gravatar image

accept rate: 6%

When I apply tcp.analysis.flags I get nothing but black and red with items like

TCP DUP ACK TCP Fast Retransmission TCP Retransmission TCP Out-Of-Order

(21 Mar '13, 11:30) freebird317

It is not nothing it got everything it has to show.Those black and red items are anomalies and their remedies. For Duplicate acknowledgements the solution tcp implements is tcp retransmission/tcp fast retransmission.Closely follow a trace by right clicking on any duplicate ack packet and selecting follow tcp stream.

(21 Mar '13, 11:33) krishnayeddula

Not always are those anomalies critical. Very often you'll see simple packet out-of-order arrivals to give you lots of duplicate acks, "TCP retransmissions" (which they aren't, just a little late) and TCP out-of-order.

In this case here I guess it is real packet loss though, because you do not get more than 1 or 2 dup acks when facing out-of-order symptoms. Here, 16 dup acks are a good sign that there is in fact real packet loss.

(21 Mar '13, 11:43) Jasper ♦♦

Looking at frame 128 - 1514 [TCP segment of a reassembled PDU] I see , for [SEQ/ACK] I am getting [reassembled PDU in frame: 166] Looking at frame 166 I see 23 Reassembled TCP Segments below that there are links to all the 23 Reassembled TCP Segments. Does this mean I am dropping packets?

(21 Mar '13, 12:43) freebird317


As @Jasper is saying, it looks like there is indeed a bit of packet loss in your network. Assuming you are running this NAS in a local network, I can imagine 2 issues that might be causing the packet loss and therefor the slow transfer speeds:

  • Your NAS and/or your client have a duplex mismatch on the switch that they are connected too
  • You have a Wifi network that might be interfered with by other networks

answered 21 Mar '13, 13:14

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%