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
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