That's what I suspected it's a custom application. Then I guess you need to work with your developer as well. Then switch and the router OS is your custom app, as well?

i don't understand "Then switch and the router OS is your custom app, as well?"

anyway , i am going to repeat this phenomenon, i will use scapy to send each sender's datagram in the capture file by manual , and see what happen on the receiver .

I mean your NOS, whether you create it by yourself or your team.

The round-trip-timer for the packet have you considered it? Maybe frame collision.

i use python scapy to repeat that capture file to make the device send that packet again , all the sender's TCP SEQ will follow what they were , the receiver's TCP SEQ will be different because of TCP protocol stack will initiate a different SEQ number , but it is not affect the result .

.144 , the receiver response a ACK 23058637730, and TCP session considerate it is correct , the no more TCP restransmission and TCP still waitting for the next packet . every thing is working fine.

but now , the question become , what makes it caculate a incorrect ACK number . i think it is a low tech mistake for a OS as a mature protocol which is working for over 20 years .

Well, you could be right. Have you tried same scenario with another OS? If it works fine, then I guess it's not the OS.

program only work on Linux , we are still testing on another kernel version .

That's a good idea to confirm which one is the culprit.