CODEWITHSUNDEEP
tcpwireshark
Tomas Kubes
Tomas Kubes

Reputation: 25098

Incorrect acknowledgements in TCP

Windows application communicate with embedded device over WiFi but it suddenly disconnects sometime. I have captured communication with Wireshark and found the last communication between the point of disconnecting. I can see that sending acknowledgement is not correct. I can See TCP Spurious retransmission and missing acknowledgement. Embedded device has IP address 192.168.1.1 and Windows PC has IP 192.168.1.2 Who to blame for these communication issues? Embedded device (192.168.1.1) or Windows App (192.168.1.2). Screenshot of packets attached.

enter image description here

Upvotes: 0

Views: 1145

Answers (1)

willyo
willyo

Reputation: 991

The "spurious retransmissions" from the embedded device indication is correct.

The "TCP acked unseen segment" indication by Wireshark is incorrect. This appears to be a Wireshark bug (which may or may not have been fixed).

See: Wireshark error with "TCP Acked unseen segment"?

What version of Wireshark are you using ?

In any case, the captured frames show that each end eventually correctly acknowledges the last data sent by the other end after which no more data is sent by either end. So, strictly speaking, there's nothing wrong at the protocol level.

What should have happened after the final frames on the connection ? More data from the embedded device ?

As seen in the capture, the embedded device:

  1. sends spurious retransmissions;
  2. bounces the "receive window size" ("Win") in a strange way seemingly having nothing to do with the actual amount of data received. (The size changes are multiples of 1460, thus suggesting a relationship to buffer availability).

So, given the choice between a Windows TCP problem (extremely unlikely) vs a problem in an unknown to me embedded device, I would choose the embedded device (especially given some strangenesses in the TCP from the device).

Upvotes: 1

Related Questions