This is a static archive of our old Q&A Site. Please post any new questions and answers at

Retransmitted vs. Out of Order packets



I have a capture maked from mobile device. In capture, I can not understand how Wireshark distinguishes retransmitted packets and out of order packets. I have the first packet transmitted with seq number 1302655196. The next two packets with this sequence number are marked as retransmitted while the others are marked as out-of-order, even though epoch time higher than the retransmitted packets. I would like to understand why.

Thank you!

asked 17 Apr '16, 21:48

Jonas%20Pontes's gravatar image

Jonas Pontes
accept rate: 0%

edited 19 Apr '16, 06:33

sindy's gravatar image


Instead of explaining what exactly you mean by epoch time (the TCP timestamp option?), could you publish the capture, login-free, somewhere like at Cloudshark (preferred), Google drive, MS One drive... and edit your Question with a link to it?

(18 Apr '16, 01:45) sindy

Epoch time is number of seconds since January 1, 1970. This is what is actually recorded in the .pcap or .pcapng file as the arrival time. This value is then converted to local time for display, based on the time zone setting of the computer.

(18 Apr '16, 08:38) Jim Aragon

OK, assuming that the OP has really used the "official" name of the frame timestamp assigned during capture, it still does not clarify everything what is missing in the question, that's why I wanted him to post the capture. Normally, all tcp packets with identical seq and ack numbers following the first one should be classified the same way. But the OP only mentions seq, so ack may be different, causing the classification to differ as well. But without seeing the actual capture, it is just a speculation.

(18 Apr '16, 11:35) sindy

alt text

The frame 89 is a transmission. The frames 90 and 91 are labeled with retransmissions, 291 and 262 are labeled with out of order. They have the same sequence number.

I'm grateful for your comments.

(18 Apr '16, 15:30) Jonas Pontes

One Answer:


OKay, so that's still not the pcap file but just a screenshot, but it tells us that both Seq and Ack values are the same for all the frames, so all of them are actually retransmissions of frame 89.

However, if you look between 91 and 261 for that TCP session's packets in the opposite direction (i.e. from to, you'll find there one whose Ack value matches (or is higher than) the Seq value of frame 89.

In another words: when frame 89 comes in, Wireshark's TCP dissector marks it as the original packet. All its retransmissions until it's been ACKed in the opposite direction are marked as retransmissions, and all its retransmissions after it's been ACKed are marked as out-of-order packets. The retransmissions 261-263 happened between the time when the ACK for 89 has passed through the interface on which you capture and the time when it has reached the sender of the 89.

answered 19 Apr '16, 05:31

sindy's gravatar image

accept rate: 24%

edited 19 Apr '16, 06:27

Yes, your statement is correct. I checked in pcap file and is what is happening. I did not know that this differentiation. Your comment was very helpful to me. Thank you.

(19 Apr '16, 06:22) Jonas Pontes

For the benefit of others asking the same question, I've converted my last comment into an Answer. Your responsibility now is to mark that Answer as the correct one using the checkmark (not thumbs up) icon. The way this site works, no one else than you can do that.

(19 Apr '16, 06:30) sindy

Can you spot SACK in the syn packets?

(19 Apr '16, 09:03) Christian_R

Sindy, additionally to my last comment, There are packets with seq number smaller than that ack number in the opposite direction, yet they are labelled as retransmitted. Why?

(19 Apr '16, 10:13) Jonas Pontes

There are packets with seq number smaller than that ack number in the opposite direction, yet they are labelled as retransmitted.

I assume you are asking why these are not marked as Out of order as well? Once again we get to the point that detailed analysis by descriptions or screenshots is almost impossible. As @Christian_R has suggested, the advanced retransmission control mechanism may have been activated for the session. This mechanism allows to inform the sender about non-contiguous portions of the stream which need to be retransmitted. While the plain Ack number informs the remote party which is the last received byte of the contiguous part of the stream, this additional mechanism informs it about non-contiguous chunks which have been received so there is no need to retransmit them.

So my original answer may actually be incorrect if those "retransmissions" differ in this part and the difference between "retransmitted" and "out-of-order" packets depends on it.

If you cannot publish the capture file due to privacy issues, have a look at tracewrangler which allows to strip payload from packets and to scramble IP addresses, so that only the information important for TCP analysis remains available.

(19 Apr '16, 15:06) sindy

Is nearly every frame 3times in your trace?

(19 Apr '16, 23:31) Christian_R
showing 5 of 6 show 1 more comments