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

Retransmitted packet is tagged as “Out of Order”?

0

Hi

Below is the screenshot taken during debug of some throughput issue. I see wireshark flagging a "802.11 retransmission packet" (please see the highlighted packet) as "TCP Out of order packet".

Third column "Sequence number" is 802.11 sequence number. Fifth column is TCP Seq No.

Let me elaborate situation: This capture is taken on wireless channel. Due to some problem the peer didn't ACK (WLAN) the TCP SYN packet. SO he has retried the same packet (with out any modifications to TCP contents). But wireshark shows that packet as Out of Order . Shouldn't it be showing TCP re-transmission instead of Out of order?

If you want to look into capture, I can upload as well.

alt text

asked 18 Feb '15, 02:35

Ramprasad's gravatar image

Ramprasad
20101115
accept rate: 0%

Can someone help to clarify my question?

(19 Feb '15, 09:24) Ramprasad

Hard to answer your question with a screenshot alone. Upload the trace to https://appliance.cloudshark.org/upload/

(21 Feb '15, 02:48) mrEEde

As the file size is large, I've trimmed the capture & uploaded with packets starting from SYN to next ~90 more packets. Please find the capture uploaded @ https://www.cloudshark.org/captures/e30a9f842f03

(21 Feb '15, 09:00) Ramprasad

2 Answers:

1

According to the code (packet-tcp.c), it's because the duplicate frames came in too fast. delta(t) < ooo_thres (3ms) - see code below.

So, to answer you question: Wireshark shows it as out-of-order because that's the way it is currently implemented, looking at a delta to determine if it's a retransmission or out-of-order.

Maybe a user-configurable parameter would be a good idea, to improve retransmission detection on very fast networks (>= 10 Gbit/s).

See also my answer to a similar question:

https://ask.wireshark.org/questions/27662/how-to-understand-out-of-order-tcp-segments

Code:

         / If the segment came relatively close since the segment with the highest
           * seen sequence number and it doesn't look like a retransmission
           * then it is an OUT-OF-ORDER segment.
           /
          t=(pinfo->fd->abs_ts.secs-tcpd->fwd->nextseqtime.secs)*1000000000;
          t=t+(pinfo->fd->abs_ts.nsecs)-tcpd->fwd->nextseqtime.nsecs;
HERE ===> if( t < ooo_thres 
      &amp;&amp; tcpd-&gt;fwd-&gt;nextseq != seq + seglen ) {
        if(!tcpd-&gt;ta) {
            tcp_analyze_get_acked_struct(pinfo-&gt;fd-&gt;num, seq, ack, TRUE, tcpd);
        }

HERE ===> tcpd->ta->flags|=TCP_A_OUT_OF_ORDER; goto finished_checking_retransmission_type; }

Regards
Kurt

answered 23 Feb ‘15, 09:32

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Hi Kurt,

Thanks for the answer. but I still have some further confusion…

I understand, as the gap is less than 3ms you don’t want to flag it as re-transmission, but is there a specific reason to mark this as out-of-order?

I was understanding, a packet can be flagged as out-of-order only if the packet with higher sequence number is there before the lower sequence number, probably due to different round trips if assymmetric routing is present? Isn’t it? Then how can packets with same sequence numbers can be flagged as Out-of-order?

(01 Mar ‘15, 05:25) Ramprasad

Then how can packets with same sequence numbers can be flagged as Out-of-order?

because that’s the way the Wireshark code currently works.

If the design is perfect or not is a totally different question, and yes you are right, flagging a repeated SYN as “out-of-order” does not sound like that should be the final solution ;-))

Please file an enhancement bug at https://bugs.wireshark.org

(02 Mar ‘15, 09:57) Kurt Knochner ♦

0

Flagging repeated SYN packets as out-of-order doesn't make sense, so I'd say this is not correctly diagnosed. You might want to open a bug report for this at the bug tracker. Other than that - since version 1.12, Wireshark considers the initial round trip time (iRTT) to determine if a packet is a retransmission or an out-of-order. So the 3ms boundary is only used when iRTT is unknown. See https://blog.packet-foo.com/2014/08/tcp-expert-updates-in-wireshark-1-12/

It is possible that the new iRTT based determination of retransmissions needs some fine tuning in some special cases where iRTT is very small or slightly missed by the retransmission. I have that one on my todo list and will probably bother the core devs at Sharkfest 2015 with some ideas on how to improve the TCP expert :-)

answered 01 Mar '15, 07:13

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks Kurt & Jasper. But....

""Flagging repeated SYN packets as out-of-order doesn't make sense ""

But my concern is mainly for TCP data packets, not just for SYN packets. I feel in no-circumstance a packet with same serial number can be flagged as out of order. Am I failing to understand something?

If my assumption is correct, I'll log bug @ provided URLs.

(04 Mar '15, 04:40) Ramprasad