This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
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.
Hi,
What is running the TCP stack on the SoC? Is it linux or some other stack is running TCP?
What is the SDK version?
Regards,
Tanmay
Hello, yes it is a linux, and the Linux kernal version is 4.4.97. And what do you menas SDK ?
hi Tanmay,
customer feedback that they are using SDK03.07.
thanks a lot!
yong
Hi Yong,
Thanks for the confirmation.
Can you compare this with the capture on the SoC side (use tcpdump -i $IFNAME -w tda2s_capture.pcap)?
if we do not see any drops from this, the issue would likely be in the tcp stack on linux. Is there any way you can try this with a newer kernel? Does this use only linux open source component, or you also have your own custom application for this. If it only uses open source components, I can try to run this on newer kernels and see if this issue is seen in them or not.
Can you share how to reproduce this issue?
Regards,
Tanmay