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

how to understand out-of-order TCP segments?

1
1

Hi, I would like to know the meaning of out-of-order TCP segments in wireshark with the following question

  1. What would make wireshark mark a segment as out-of-order?
  2. IP layer should re-order IP packets correctly and then give them to TCP, why could out-of-order occur?
  3. Does out-of-order always mean bad things?
  4. What should we do when we see out-of-order TCP segments, especially when there are lots of them.

thank you!

asked 02 Dec '13, 07:29

SteveZhou's gravatar image

SteveZhou
191273034
accept rate: 0%


2 Answers:

1
  1. The SEQ number is not what Wireshark would have expected as next SEQ number (see below)
  2. Different devices on the way my handle IP packets differently, and thus forwarding one frame earlier/later than another. Or different IP frames take different routes (rather seldom).
  3. No, if it's not too many of them
  4. Figure out what causes them. Capture at the sender and the receiver side and compare the capture files. If that does not help, move along the path and take captures at different places (if possible - obviously a problem if the data path 'crosses' the internet). Make sure, the 'out-of-order' frames aren't just duplicated frames, by checking the IP ID (try to find duplicate IP IDs).

From packet-tcp.c:

       
       /* If the segment came <3ms 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.
         *   (3ms is an arbitrary number)
         */
    t=(pinfo-&gt;fd-&gt;abs_ts.secs-tcpd-&gt;fwd-&gt;nextseqtime.secs)*1000000000;
    t=t+(pinfo-&gt;fd-&gt;abs_ts.nsecs)-tcpd-&gt;fwd-&gt;nextseqtime.nsecs;
    if( t&lt;3000000
    &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);
        }
        tcpd-&gt;ta-&gt;flags|=TCP_A_OUT_OF_ORDER;
        goto finished_checking_retransmission_type;
    }</code></pre><p>BTW: See also other questions with the tag: out-of-order</p><blockquote><p><a href="http://ask.wireshark.org/tags/out-of-order/">http://ask.wireshark.org/tags/out-of-order/</a></p></blockquote><p>Basically the same explanation as I gave above, just different (real world) examples ;-))</p><p>Regards<br />

Kurt

answered 02 Dec ‘13, 07:42

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 02 Dec ‘13, 08:20

So IP doesn’t have the responsibility to put the packets in a right order, does it? It is TCP’s job, what if the application layer protocol doesn’t use TCP? Who will put the packets in a right order? Application layer protocol?

(04 Dec ‘13, 07:20) SteveZhou
1

So IP doesn’t have the responsibility to put the packets in a right order

No. The job of IP is just to route/transport the frames to the destination, regardless of packet order or the way/path it chooses.

It is TCP’s job,

For TCP: Yes, it’s TCP that will deliver data in the right order to the application, which will/can cause delays if you have a lot of out-of-order packets, as TCP must wait until all required segments have arrived.

Who will put the packets in a right order? Application layer protocol?

the application itself or the ‘application protocol’, if that is implemented ‘outside’ of the application - for whatever reason.

(04 Dec ‘13, 07:23) Kurt Knochner ♦

thanks a lot!

(07 Dec ‘13, 08:20) SteveZhou

Your “answer” has been converted to a comment as that’s how this site works. Please read the FAQ for more information.

(07 Dec ‘13, 08:29) grahamb ♦

0

A common reason why Wireshark marks certain segments "Out-of-order" is because of a known bug in Wireshark:

In a sequence like the following:

1) A ------SYN-----> B

2) A <-----SYN------ B

3) A ----SYN/ACK---> B

, Wireshark will mark segment 3) "Out-of-order".

This is of course a mistake. This sequence is a normal TCP sequence, often called "TCP simultaneous connect". Since P2P applications use TCP simultaneous connect a lot to perform TCP NAT punching, you might see such sequences and false positives often.

Someone at Wireshark should fix it imho, it looks bad when a network analyzer doesn't understand the basic TCP state diagram.

answered 05 Jun '14, 15:27

abdul's gravatar image

abdul
11
accept rate: 0%

edited 05 Jun '14, 15:29

Hi Abdul, do you have a bug ID for this known issue? I'm really curious about it. I'm seeing TCP out-of-order packets and I'm wondering if it could be related.

(16 Jun '14, 13:11) calpolygrad

A common reason why Wireshark marks certain segments "Out-of-order" is because of a known bug in Wireshark:

@abdul: can you post a sample capture file (google drive, dropbox, cloudshark.org) that shows the mentioned behavior?

(17 Jun '14, 11:51) Kurt Knochner ♦

I have a capture example of what Abdul is talking about:

67  11:11:17.7  74.118.32.157   209.112.4.11    TCP 66  https > 50486 [SYN, ACK] Seq=0 Ack=1 Win=4140 Len=0 MSS=1460 WS=1 SACK<em>PERM=1

68 11:11:17.7 74.118.32.157 209.112.4.11 TCP 66 [TCP Out-Of-Order] https > 50486 [SYN, ACK] Seq=0 Ack=1 Win=4140 Len=0 MSS=1460 WS=1 SACK</em>PERM=1

(04 Aug ‘14, 11:53) Frank Murray

Can you post the capture somewhere? what were the circumstances of the capture?

(04 Aug ‘14, 12:03) grahamb ♦

@frank murray did you see grahamb’s comment?

(07 Apr ‘15, 10:08) barlop