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:
Any help would be appreciated. asked 08 Jun '12, 11:15 ArFrog edited 08 Jun '12, 14:22 SYN-bit ♦♦ |
One Answer:
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 ♦♦ 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 |
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...
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.