TCP ACK number incorrect

[gbcbooksmj]

please check the attachment, it is receiver , all the tcp seq and ack number are real.

please look at the high line ack = 2305863558 , is it correct ? or should it be the the last tcp datagram 's SEQ + len it received , which is ack = 2305863644 + 86 .

and tcp restrasmission happen more the 10 times on this packet

and this is capture file from TCP sender 

it receive this packet more then one time , but , it still consider it as a no ack status .

it is possible dropped by the system because of the incorrect ACK number?

our current kernel version is Linux kickseed 4.9.20-040920-generic

from the wireshark tips,  6th packet as the picture shows . the wireshark tells it next SEQ sould be 2305863730, it just equal 2305863644 + 86

i am sorry to post a TCP problem here , but i don't know what else forum community will interesting of TCP protocol .

[rais]

.144 is saying that it received data up to the sequence 230...63558. Which means it's not getting anything.  

In packet #5, however, it did ACK one 86 byte packet when it used ACK = 2305863644. It reverted back to 2305863558 for some reason. If #s are correct, it's not receiving/ACKing any of the 86 byte packets....hence the retransmissions. 

[Vasilii Mikhailovskii]

Hello.

I agree it's not expected, that .144 first ACK 2305863644, but later ACK 2305863558.

Could you clarify on which side did you do the capture - .68 or .144?

I would try to disable TCP offload and repeat the test; also capture on any device in the middle could really help to understand the situation.

In case you are using a firewall or traffic optimization - try to capture traffic on a segment not affected by the devices.

[gbcbooksmj]

the first pic is capture on .144 , the TCP receiver , and the 2nd pic is capture on .68  the TCP sender 

.

why do you recommand to capture on the middle device ? 

[gbcbooksmj]

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 . 

please check the capture file below . 

.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 .