Tool/software:
In recent days, we found an un-correct behavior about TDA2S's TCP protocol.
Please have a look of upper picture and let me elaborate the issue.
The IP address 172.16.2.92 represents TDA2S.
At #47528 , other node sent a PDU to TDA2S, the seq=30316112 and length=1448. We can see that after this, TDA2S didn't answer ACK for this PDU.
Then, at #47530，#47531，#47532 other node continuously sent 3 PDUs to TDA2S. So that till now other node has sent the PDUs[ from 30316112 to 30321904 , total length is 5792] to TDA2S.
At#47533, TDA2S replied ack=30316112 to show what it has received, besides it also replied that it received [30317560 - 30319008]. Now we can see that TDA2S are lack of the part of [ 30316112+1448]
Then at #47534, TDA2S replied ack=30316112 again and still be lack of [30316112+1448]
So other nodes at #47535 to make a retransmission to complete [30316112+1448]
But other nodes afterwards didn't get ack response for [30316112+1448] so that at #47541,#47545 it continuously sent retransmission to TDA2S.
But from the perspective of TDA2S, because it is not able receive the [30316112+1448] from other nodes, it low down the interaction messages as [TCP Keep-Alive] and meanwhile it continuously complained for cannot receive the part of [30316112+1448]
Other nodes continuously sent retransmission for completing the [30316112+1448] at #47556 and #47575, again TDA2S cointinuously compained about be lack of [30316112+1448] at following TCP keep-ALive message.
Finally, maybe other nodes think this connection is bad so launch a RST to dis-connect it.
So the conclusion is TDA2S cannot receive the retransmission from the other node to complete its lacking part.
