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 from the 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

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

any reply ?

any body interested in this question ?

I think there's no problem, make sure you understand how packet framing works.

TCP is a reliable protocol, which basically means that if the packet is dropped, lost in transit or corrupted.

The frame will be reassembled in sequence until the whole packet is in order, after a number of times of trying and not able to get the packet in order that will be the time that the application will throw an error.

What issue are you experiencing? Downloading from the internet and every time the data is corrupted?

The sequence number is decided by the Layer 3 in the OSI model (network layer) and is decided by both parties (two end devices).

You don't add the sequence number like that it's incremented by one only.

Don't dive too deep, learn the basics of OSI. Mileage will always vary, don't be in a hurry unless you don't have other priorities.

thks for reply , yes , of course TCP SEQ is completed by the Network layer , and we dont need to bother it. but knowing well how TCP works it is good for our job, isn't it .

and it is a really case in my business of my machine . it might be the root cause of our issue .

in normal time , we should believe that Layer 3 always working find , few situation that TCP will send a incorrect ack number . if it is so, the receiver will absolutely drop the incorrect ACK packet . so i was asking you guys think this issue is really happening on this machine .

It's quite hard to get into depth, but if there's an issue in your network; I would check on your network card interface, network cables, network switches, routers and even your bandwidth whether it's stable or not.


If everything doesn't work well, then I guess it could be some malware changing the packets in transit but someone should be very determine to hack your network because changing or modifying network packets requires a high level of network knowledge and programming.

Search duckduckgo.com, Google or any of your favorite search engine this keywords: "Packets replay"

What is that issue, you're talking about? Like what? (layman terms please)

Analyzing network packets it's not easy as eating a pie, and it will take a definite amount of time to analyse it.

Sorry, I can't help you to get into details of it.

sorry , i did not see your first post .
two of our server will establish TCP connection and send data flow period . most of time they are working fine . but in a low rate , TCP data can not be sent and data are stock.

from the capture file , we see that the last ACK number of last TCP ack packet it wrong , by restramsit 15 times , TCP connection will be rest and open a new TCP session between this two machine . for our business , wait 15 time to restramsit is too long , and unacceptable .

so we want to fine out what cause the ack number incorrect, kernel ?
from this issue , we can reduce the times of tcp restramsit. but who can guarantee that the appearance rate of this issue

Are you using a custom application to transfer data or create a TCP connection?

The two machine is in the same network? or it's on a remote host?

i m a network engineer , the rule of generating TCP SEQ is not so complicated as you think at less i think so .

the thing i can not believe that is TCP protocol stack i used to believe so hard would have a suck a stupid problem . i want somebody to tell me that i was wrong .

Ahh okay, in low rate there's an error. Maybe the frame is too large for the bandwidth. Or there's a packet collision in between transit.

If the two machine is on a remote host, is it using a BGP network, frame relay or what?

If you think it's a kernel issue then search the web whether it's a common issue.

But I suppose you're experimenting sending packets in low bandwidth, there are a lot of things to consider. My pay grade is unable to adapt such things. LOL.

yes , application layer is custom , we developer they only care application layer , layer 4 will be completed by kernel or protocol stack .

this two machine exist in two IDC

no , because of the sender received receiver's ack , even most of 15 retramsission packet were lost .

Ohh, here comes the truth you're a network engineer then I guess you should be able to solve it. Just take it slowly, maybe tomorrow you will be able to figure it out. Maybe it just need a can of beer relaxing under the moon light. hahaha.

I'm a Sys Admin, so your network skills will be 1 billion percent better than me.