I have a capture file made on a unix server which has duplicate ACK's in there which are very close in time (0.000012) to the original packet it is a duplicate for. Nor do the DUP acks in this trace ever trigger a retransmission. http://www.cs.unc.edu/~jeffay/dirt/FAQ/dupacks.html So I stumbled on the above link, stating that "the book" actually has an explanation. Solitary Duplicate ACK with different window sizes can be part of the window update mechanism. If the above is does the DUP ACK packet need to have a different window size value? asked 14 Dec '12, 05:24  dtor |
2 Answers:
What you're experiencing is most likely a duplicate frame created by the way you captured the data. 12 microseconds is way too fast for a normal duplicate ACK to appear on the wire. You can easily check if it is a duplicate frame by comparing it byte by byte - if it is a normal duplicate ACK at least the IP Identification byte is different (unless you're looking at some high security trace setting it to 0 all the time). Try running editcap -d against the trace to remove duplicates. editcap is installed with Wireshark and is a command line tool that you'll find in the program folder of Wireshark. answered 14 Dec '12, 05:36  Jasper ♦♦ edited 14 Dec '12, 05:36 |
There is something broken on your system or the capture setup is faulty. The SRC MAC of all packets is identical! Unless you have found the reason for that problem, I would not care too much about the DUP-ACK as the same problem could also cause those DUP-ACKs ;-) Regards answered 14 Dec '12, 07:00  Kurt Knochner ♦ edited 14 Dec '12, 07:09 hello Kurt, Well that may be my own fault, I had to scrub the data. (14 Dec '12, 07:45) dtor hm.. can you please post a more concise capture file? Otherwise it's hard to analyze it. BTW: Your "data scrubbing" did not change the time stamps, did it? (14 Dec '12, 07:50) Kurt Knochner ♦ not the timestamps I checked with the original it only appended 000. Just ip and mac. (14 Dec '12, 08:05) dtor O.K. as already mentioned, the DUP-ACKs are to fast to be real. So, I guess there is a bug in your OS that causes those packets to be sent twice immediately one after each other (same content, different IP ID). The system that sends the DUP-ACKs seems to be Windows. Is that correct? If so, what is your OS version (looks like Win XP). To eliminate any interaction with the capturing software on your Unix box, I suggest to also capture on the Windows box and to check if you see the DUP-ACKs there as well. (14 Dec '12, 10:17) Kurt Knochner ♦ I believe our client is using windows. I will do a network capture on the client side and see what comes up. Thank you for the input (15 Dec '12, 05:03) dtor We mirrored the clients port and saw the dup acks heading towards the server. We'll be looking at the clients software/drivers/firmware.. Thank you for your time and input. (18 Dec '12, 01:32) dtor O.K. good luck. I suggest to look at OS patches and the NIC driver if TCP offloading (or any other offloading) is enabled on that NIC. You can also try to disable TCP/IP offloading (driver feature). Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions. (18 Dec '12, 01:36) Kurt Knochner ♦ showing 5 of 7 show 2 more comments |
I have checked the IP ID, but they do differ.
I have uploaded a capture of a tcp session which has this behaviour
http://cloudshark.org/captures/580b1f12dc02
interesting... you're right, they're not duplicate frames. Where and how did you capture this trace? My guess is that it was captured locally on the server, which can lead to funny results. Can you capture again, with a 3rd PC that picks up what client and server are doing? That way we could see what really happens on the "wire".
thank you for your comments.
The capture was made on the server (112). Your second request is harder, there are more networkdevices involved to which do not have access.
I will try and find a good spot so to do a capture. but that can take a while.
Well, if you only wonder about the duplicate ACKs you can probably ignore them - they do not cost any time, and there is no packet loss either, so no harm done. My guess is they disappear as soon as the capture setup is done right without capturing locally.