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

Vendor claims Wireshark incorrectly reporting Out of Order Packets

0

I am getting traces from TCP Dump from interface of EMC NAS device sending from one network over MPLS WAN to another NAS device. TCP Dump taken from both sending and receiving end. Since we saw out of order reported in trace file of sending device, we assumed it was happening at device. However, the vendor (EMC) says that this is a known problem with the Wireshark dissector. That they have written their own to solve the problem. That they are actually retransmissions and not out of order. We can see that the SEQ's are not coming out in order (not just relying on expert message).

They said the way to know is to look at the IP ID. If you look at the packets that the sender is sending, the IP ID's are sequential. However, the "next SEQ" that is expected is not in the right order so Wirehshark is saying out of order.

Is it true that if IP ID's are sequential, they are not out of order? They are arriving out of order on the remote side after traversing MPLS network which is not a big surprise but in order to prove it's happening while on the WAN, we have to figure out if Wireshark is incorrect in saying they are out of order when taken from the source host. Has anyone heard of this? EMC is calling it "False Positives". The good news is we actually have a vendor who uses Wireshark! Thanks.

asked 16 May '12, 14:37

Janis%20Bishop's gravatar image

Janis Bishop
1●2●2●2
accept rate: 0%

One Answer:

0

If Wireshark reports "Out-of-order" packets at the TCP layer, it means that packets are seen which are not yet expected in respect to the sequence numbers of the packets. This does not say anything about whether the packets were re-ordered on the way. They could very well be sent out-of-order to begin with. Maybe this is what EMC means by "looking at the IP-id". Usually traffic between two hosts uses IP-id's that are increasing by 1 for each new IP datagram.

Without a trace file it is very hard to tell what's going on. Can you upload a small example file to www.cloudshark.org and post the link here?

answered 16 May '12, 14:57

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

I'm not sure I am allowed to do that, so will check.

(16 May '12, 15:14) Janis Bishop

(I converted your "answer" to a "comment", as that's the way this site works best, please see the FAQ)

Yes, please DO check whether (a part of) the file can be posted. If not, you can also post the output of the command:

tshark -r <file> -T fields -e tcp.srcport -e tcp.dstport -e ip.id -e tcp.seq -e tcp.len -e tcp.ack -e tcp.analysis.out_of_order

this will not disclose any sensitive information and will give us an idea on what is going on.

(16 May '12, 15:33) SYN-bit ♦♦

Could you please add the timestamp, as the "out of order" detection (also) relies on a time delta (see 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)
    */

tshark -r <file> -T fields -e frame.time_epoch -e tcp.srcport -e tcp.dstport -e ip.id -e tcp.seq -e tcp.len -e tcp.ack -e tcp.analysis.out_of_order

(16 May '12, 16:16) Kurt Knochner ♦

better use the filter frame.time_relative

(17 May '12, 00:35) Kurt Knochner ♦