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 |
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 ♦♦ |
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 |
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:
answered 21 Mar '13, 13:14  SYN-bit ♦♦ |
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
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.
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.
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?