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

Why am I getting duplicate tcp acks?

0

I have an application I've written on Windows 7 that is connecting TCP to a custom device. The device is sending status packets approx. every 25ms to the host. The device is also running code I've written. They are connected ethernet via a DSL router. The application is also sending data over a second TCP port to the device.

All works well until I get a duplicate ACK from the host. The orignal packet from device to host shows up in Wireshark. After the 3rd DUP ACK, the device sends a fast retransmit of the packet. The host keeps sending DUP ACKs for a total of 7. The device keeps sending it's status updates every 25ms. After about 1 sec. the device re-transmits these status packets. Meanwhile, a thread on the host has a recv() active with a 5sec. timeout. This recv eventually times out and then disconnects. During this time, the host is continuing to send data on the other port. So, the sequence shown in Wireshark seems OK, but the application times out waiting for data.

Thus, various questions that I hope someone can help me understand:

  • all the packets show up in the Wireshark trace, so what might cause Windows to issue the DUP ACK (Wireshark is running on the same machine)?
  • what might be causing the host to not receive the data (either the original or re-trans)?
  • if, for some reason, the receive thread on the host is locked up, would this cause these symptoms (i.e. if the receive buffers are all full, will this cause DUP ACKs? The window size from the host never drops...).

Any help would be appreciated.

asked 08 Jun '12, 11:15

ArFrog's gravatar image

ArFrog
1111
accept rate: 0%

edited 08 Jun '12, 14:22

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245

Can you upload the tracefile to www.cloudshark.org and post the link to the file here? That makes discussion on what might be happening in your case a lot easier...

(08 Jun '12, 14:23) SYN-bit ♦♦

I uploaded the capture file to http://www.cloudshark.org/captures/96ee8678c779 192.168.0.37 is the device, 192.168.0.3 is the host PC. Port 27015 is the command/status port, 27016 is a data port. At sequence 675 is the last received status packet, 881 - dup ack #1, 900 - fast retrans, 1793 full retrans and at 5673 is the RST due to the host application detecting the recv timeout.

(08 Jun '12, 15:59) ArFrog

One Answer:

0

The packets are received by the host (as can be seen in Wireshark), but they never reach the application as the TCP checksums are incorrect. Something on the device is messing up the checksums.

answered 08 Jun '12, 18:21

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Thanks for the quick response. I had checksum verification off since all the host packets were flagged in error, so didn't see that these few packets from the device were in error. Now I can track the culprit down... Thanks again.

(08 Jun '12, 19:13) ArFrog