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

TCP Out-of-order VS Retransmission

I've got a situation where there appears to be timeouts on the client side. I've zeroed in on a sample, but I see this multiple places. The dialog is going fine and the client sends 67 bytes of data in #1478 and the host is ACKs in #1479. The client then sends the same sequence packet as it did in #1478, but the data is larger. In fact, it contains everything #1478 did, plus the next block of data it was to send. This was reported as a TCP Out-of-order as opposed to a retransmission.

Is this considered an out-of-order because the second packet was different in its data portion (seq and ack were the same)?
Am I reading this correctly that the client never saw the ACK in #1479? It was 27 seconds before the out-of-order packet came in that duplicated the data in #1478. It seems like if the client did not get the ACK it it would have retransmitted earlier.
Is it normal to see the same packet sequence number sent with additional data? I guess this can only happen when an ack is dropped and in the meantime additional data was written right?

start of edit on 3/28 >>>

4) Assuming the ACK in #1479 was dropped caused the retransmission, albiet with additional data, to happen in #1480, what can be learned from the fact that the retransmission was 27 seconds later? Shouldn't the retransmission have happened (with or without subsequent data) every half second or so?

Some additional information, that second set of data that was appended was a new request to the host and could have have been sent any number of seconds later. I am envisioning a problem on the client side of the network and then, with the additional data being added somehow clearing up the problem and allowing the larger frame through a faulty wireless AP or router?

<<< end of edit on 3/28

Thanks for any insights!

(5101 is the host)

No. Time Source Destination Protocol Info

1474 11:33:11.197 200.10.10.147 200.10.10.33 TCP 1061 > 5101 [PSH, ACK] Seq=657606914 Ack=3891546886 Win=32220 Len=255

1475 11:33:11.258 200.10.10.33 200.10.10.147 TCP 5101 > 1061 [PSH, ACK] Seq=3891546886 Ack=657607169 Win=65213 Len=39

1476 11:33:11.462 200.10.10.147 200.10.10.33 TCP 1061 > 5101 [ACK] Seq=657607169 Ack=3891546925 Win=32181 Len=0

1477 11:33:11.462 200.10.10.33 200.10.10.147 TCP 5101 > 1061 [PSH, ACK] Seq=3891546925 Ack=657607169 Win=65213 Len=213

1478 11:33:11.483 200.10.10.147 200.10.10.33 TCP 1061 > 5101 [PSH, ACK] Seq=657607169 Ack=3891547138 Win=31968 Len=67

1479 11:33:11.615 200.10.10.33 200.10.10.147 TCP 5101 > 1061 [ACK] Seq=3891547138 Ack=657607236 Win=65146 Len=0

1480 11:33:38.671 200.10.10.147 200.10.10.33 TCP [TCP Out-Of-Order] 1061 > 5101 [PSH, ACK] Seq=657607169 Ack=3891547138 Win=31968 Len=350

1481 11:33:38.729 200.10.10.33 200.10.10.147 TCP 5101 > 1061 [PSH, ACK] Seq=3891547138 Ack=657607519 Win=65535 Len=39

1482 11:33:38.871 200.10.10.147 200.10.10.33 TCP [TCP Previous segment lost] 1061 > 5101 [ACK] Seq=657607519 Ack=3891547177 Win=31929 Len=0

1483 11:33:38.947 200.10.10.33 200.10.10.147 TCP 5101 > 1061 [PSH, ACK] Seq=3891547177 Ack=657607519 Win=65535 Len=204

1484 11:33:39.073 200.10.10.147 200.10.10.33 TCP 1061 > 5101 [ACK] Seq=657607519 Ack=3891547381 Win=31725 Len=0

1485 11:33:57.861 200.10.10.147 200.10.10.33 TCP [TCP Dup ACK 1484#1] 1061 > 5101 [ACK] Seq=657607519 Ack=3891547381 Win=31725 Len=0

ack out-of-order

asked 25 Mar '11, 13:33

motdc
6●1●1●4
accept rate: 0%

edited 28 Mar '11, 06:54

2 Answers:

For (1): this problem was actually just fixed in Wireshark yesterday (rev 36323). You can pick up an automated build (with that rev or higher) to check it out; now Wireshark will only call it a retransmission instead of out-of-order.

For (2): Yes, that seems like it is the case.

For (3): I saw it once years ago too, so I suppose it's relatively normal (but I definitely not a TCP expert).

answered 25 Mar '11, 14:40

JeffMorriss ♦
6.2k●5●72
accept rate: 27%

Thanks for the info that it was just fixed! I'll have to download it today.

(28 Mar '11, 05:43) motdc

Yes to #3. TCP is a stream based protocol. So instead of just retransmitting what went missing, it will try to take the full load of data if available. So the SEQ# demarcs the start of the segment. The fact that it has additional payload doesn't change the start of the segment. Only the TCP LEN changes.

answered 25 Mar '11, 16:08

hansangb
791●2●6●19
accept rate: 12%

I can see how the second frame received from the client would have a superset of the data in the case of a lost ACK. What troubles me is that 27 seconds had passed betwwen the first and second frame. If the ACK were dropped then the client would be retransimitting (both before and after the next set of data was appended) every 1/2 second. That still seems fishy to me.

(28 Mar '11, 05:50) motdc

It's hard to follow your text output - not dedicated enough to follow it via txt output! :) If the sender does not get an ack from the receiver, the RTO should trigger a retransmission. It shouldn't be 27 seconds, so I do agree that something fishy is going on. If the sender is not that busy, take a look at the IP ID to see if there is a sudden jump in the 27 second window. Perhaps it was retransmitting and you missed that as well. That would be one explanation.

(28 Mar '11, 18:45) hansangb