2

Introduction of the application

We have an application which it receive data from a TCP protocol (IOT device) to our Ubuntu server. Both end send it's data receive confirmation to each other, in order maintain it's communication and accept the next respective message.

Problem

Often times we noticed the server receive duplicate data. This only happens if the IOT device lost or got interrupted the connection with the server. Basically if the device didn't receive any information from the server it keep retransmitting the duplicate data.

What we found

We took a tcpdump from the server and examined with the Wire Shark software. We noticed before the device sends duplicate data at that time period, there were few entries of server keep trying TCP Retransmission/TCP DUP ACK (see the attached - black highlighted rows). We think this was the cause of the problem to receive duplicate data from the device because according to the Wire Shark logs device didn't properly receive the confirmation from the server.

enter image description here

Queston

  1. Is there a way we can eliminate the TCP Retransmission/TCP DUP ACK from the serer end? I mean by increasing the waiting time interval of each transmission? or any other?

  2. Or this problem purely relies on the device connectivity?

  3. Any other method to investigate this problem?

FR STAR
  • 121

1 Answers1

0

I think what you're describing is completely normal behavior of TCP communication in a situation where there is no response from the opposite party fast enough.

Look at the 101596 and 101611 packets. Because there has been no response to the 1015946 [FIN, ACK] packet sent by party A from party B for 744 ms, party A sends the same packet again. It is the sequence number 101611 . Wireshark sees it as a duplicate, which it really is. The time difference is 14:52:01.188-14:52:00.444=744 miliseconds.

Since in another 1472 ms again there was no response from B, side A tries again (for the third time) with a packet 101634.

Then the connection was restored. There was a duplicate response from party B, which received delayed multiple packets from party A. Etc.

It is a feature of the TCP connection that when it does not receive a response, it repeats the same packet over and over again. After a long timeout after multiple attempts, it can then declare the connection unsuccessful and terminate it prematurely.

  1. In my opinion, there is no reason to artificially remove duplicate packets. Ensure that the connection is not interrupted and the other party responds in a timely manner. Then the duplicates disappear.
  2. Yes, this problem purely relies on the device connectivity.
  3. As an analysis method, you can use detailed analysis of TCP sequences and monitoring of packet times.
netbat
  • 1,221