Ask Your Question
0

How does wireshark determine if a TCP packet is out-of-order?

asked 2019-05-11 18:32:30 +0000

updated 2019-05-12 04:08:15 +0000

Guy Harris gravatar image

Folks

I saw this dump on a different forum but the real cause wasn't explained properly image description

I will assume the first packet seen is number 1, my concern is with packets 12, 14 and 15

10. 192.168.1.100 → 198.41.209.139: SEQ=661 – ACK=8205 [ACK] → OK
11. 198.41.209.139 → 192.168.1.100: SEQ=8205 – ACK=661 [ACK] → OK
12. 198.41.209.139 → 192.168.1.100: SEQ=12525 – ACK=661 [PSH, ACK] → Bad
13. 192.168.1.100 → 198.41.209.139: SEQ=661 – ACK=9645 [ACK] → OK
14. 198.41.209.139 → 192.168.1.100: SEQ=9645 – ACK=661 [ACK] → Bad
15. 198.41.209.139 → 192.168.1.100: SEQ=11085 – ACK=661 [ACK] → Bad

1st Concern: Looking at PKT 14 I'm not able to determine why it is out-of-order! If it came before PKT 13 like below would it be OK?

****198.41.209.139 → 192.168.1.100: SEQ=9645 – ACK=661 [ACK]
13. 192.168.1.100 → 198.41.209.139: SEQ=661 – ACK=9645 [ACK]

2nd Concern: PKT 12 is seeing that a previous TCP segment wasn't captured, is it referring to PKT 15 which came late? So if I saw it like below would it be considered OK?

11. 198.41.209.139 → 192.168.1.100: SEQ=8205 – ACK=661 [ACK]
****198.41.209.139 → 192.168.1.100: SEQ=11085 – ACK=661 [ACK]
12. 198.41.209.139 → 192.168.1.100: SEQ=12525 – ACK=661 [PSH, ACK]

How does wireshark determine if a packet is out-of-order?

Thanks,

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted
1

answered 2019-05-12 15:07:21 +0000

SYN-bit gravatar image

Some comments in the source code of the TCP dissector kind of explain it:

/* RETRANSMISSION/FAST RETRANSMISSION/OUT-OF-ORDER
 * If the segment contains data (or is a SYN or a FIN) and
 * if it does not advance the sequence number, it must be one
 * of these three.
 * Only test for this if we know what the seq number should be
 * (tcpd->fwd->nextseq)
 *
 * Note that a simple KeepAlive is not a retransmission
 */

So, first condition to match is that the received segment does not have a sequence number that is equal to (or higher than) the next expected sequence number.

Then later on (after checking if the packet was a fast-retransmission):

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

And in the code below that, it compares the delta time between this frame and the time of the frame with the highest received sequence number. If that delta is less than the initial round-trip time (or less than 3 ms when the 3-way-handshake was not captured), it is considered an out-of-order packet.

So in the case above, the proper order for packets from X to arrive would have been:

11. 198.41.209.139 → 192.168.1.100: SEQ=8205 – ACK=661 [ACK]
14. 198.41.209.139 → 192.168.1.100: SEQ=9645 – ACK=661 [ACK]
15. 198.41.209.139 → 192.168.1.100: SEQ=11085 – ACK=661 [ACK]
12. 198.41.209.139 → 192.168.1.100: SEQ=12525 – ACK=661 [PSH, ACK]

You could say that only frame 12 was received out-of-order, the rest was fine.

However, Wireshark interprets the packets as they come in and only keeps little state of the session to base the analysis on. This means when the packets arrive in this order:

11. 198.41.209.139 → 192.168.1.100: SEQ=8205 – ACK=661 [ACK]
12. 198.41.209.139 → 192.168.1.100: SEQ=12525 – ACK=661 [PSH, ACK]
14. 198.41.209.139 → 192.168.1.100: SEQ=9645 – ACK=661 [ACK]
15. 198.41.209.139 → 192.168.1.100: SEQ=11085 – ACK=661 [ACK]

The only thing it knows when packet 12 arrives is that there is data missing, hence the "Previous Segment not captured". Then when it receives frame 14, the sequence number is not advancing (as frame 12 has a higher sequence number) and the frame was received quickly, so it could not have been a retransmission. Therefor it labels it as an out-of-order. The same goes for packet 15.

edit flag offensive delete link more

Comments

I see, PKT 12 was misleading to me but now I got it, I've also bookmarked wireshark github page and will look more into packet-tcp.c later on

Thanks a bunch

saeedbeliever gravatar imagesaeedbeliever ( 2019-05-13 22:59:00 +0000 )edit
0

answered 2019-05-11 23:36:55 +0000

Jasper gravatar image

Doing this from a screenshot is suboptimal at best, especially without packet numbers, but let's try. If I get it wrong I'm sure @SYN-bit and @Packet_vlad will correct me :-)

One thing is easy: packet #12 has a higher sequence number than packets #14 and #15, so there's a gap before it and that leads to the symptom "previous segment not captured".

This also makes both #14 and #15 either a retransmission or out-of-order, because they both should have arrived before #12 (and still #14 before #15). Wireshark has some logic to determine if a packet arriving late is a retransmission or just switched places during travel across the network. Basically it tries to determine if the sender could have known that a packet was lost or not, and that's depending on the initial round trip time (iRTT). We don't know the RTT here because it's just a screenshot, so it's either that 14 and 15 arrived faster than iRTT, or arrived within a couple of milliseconds after where they should have arrived.

So no, 1st concern assumption is not correct. #14 coming before #13 is not the problem. Both #14 and #15 should have arrived before #12.

2nd concern: the symptom in #12 means both #14 and #15, not just #15. Wireshark sees that a sequence number in #12 is higher than what's expected, so it states "previous segment not captured", which may be a bit misleading in this case - it should be "previous segment(s) not captured")

edit flag offensive delete link more

Comments

Gotchya! It makes total sense

Thanks a bunch

saeedbeliever gravatar imagesaeedbeliever ( 2019-05-13 22:55:34 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-05-11 18:32:30 +0000

Seen: 736 times

Last updated: May 12