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

Duplicate ACKs + delayed retransmission (part 2)

This is a followup question from an earlier post whihc was answered by SYN-bit: I just realized something that does not make sense to me in the capture: Wireshark and the program I am using to perform the nttcp test (nttcp under Cygwin) are executed on the same machine: how is it possible that Wireshark captures all packets, but my nttcp program misses them? Or am I misinterpreting the results here?

The capture is located here.

Thanks! Dirk

duplicateacks 821

asked 18 Feb '15, 13:03

djbuijs
11●2●2●5
accept rate: 0%

One Answer:

"... how is it possible that Wireshark captures all packets, but my nttcp program misses them?"
The application received all bytes that were sent on the data connection. The ack number in the FIN packet is is the number of bytes received (plus 2 for SYN and FIN bit).
Using TCP protocol, the application is not aware of packets but just passes a byte-stream to the send buffer. TCP will segment the data and send it in IP packets over the network. In case a packet get lost, TCP as a reliable transport will take care of re-transmitting the packet (without any notification/intervention of the application).
So the difference of the data see in your application and the data that was traced should only be the retransmitted packets, packets 51 and and 124 in your capture.
Regards Matthias

alt text

" but there's still the issue of the Duplicate ACKS, which suggests that somewhere in a lower layer packets got dropped. However, Wireshark seems to have managed to capture all packets!"

Well, this trace does not contain all packets that were actually flowing as dumpcap couldn't keep up with the amount of traffic. And, the packets are not necessarily 'dropped in the lower layer'.

In your case the packets are dropped in the TCP layer of Windows7 because the TCP checksum is incorrect in packets that caused the duplicate ACKs. _ws.expert.severity gt "warn" will yield those packets if you enable TCP checksum validation in the protocol preferences.

alt text

answered 21 Feb '15, 02:41

mrEEde
3.9k●15●22●70
accept rate: 20%

edited 22 Feb '15, 02:20

Hi Matthias, Thanks for your help on this. It's still a bit of a mystery what is going on exactly. I understand the way TCP is basically a pipe when seem from the application layer, but there's still the issue of the Duplicate ACKS, which suggests that somewhere in a lower layer packets got dropped. However, Wireshark seems to have managed to capture all packets!

Regards, Dirk

(21 Feb '15, 22:13) djbuijs