[Simone Ferlin-Oliveira <ferlin@xxxxxxxxx>]

Thanks Jim,

I am exactly in this point trying to distinguish between retransmission from packet out of order from actual packet loss on

the link. I knew about this possible misidentification from wireshark concerning retransmission. Somebody in the forum

posted a possible combination of retransmission followed by lost_segment to identify actual packet losses.

One of the flows I am analyzing is from a network that has big buffers and I get lots of retransmissions at the sender that

are not real packet losses caused by the link quality.

On 31 August 2013 20:40, Jim Aragon <Jim@xxxxxxxxxxxxxxxxx> wrote:

At 10:47 AM 8/30/2013, you wrote:

I am investigating several TCP flows and I am wondering how you can proper filter packet loss in tshark/wireshark:

In the forum someone says that the correct way of filtering lost packets and looking for tcp.analysis.lost_segments followed by tcp.analysis.retransmissions. What about tcp.analysis.ack_lost_segments?

I would simply filter on tcp.analysis.retransmissions. This will show you all packets that Wireshark identifies as retransmissions. However, be aware that Wireshark can mis-identify retransmissions. If there is a gap in the sequence numbers, Wireshark will identify any packet that shows up within 3 ms of when it should have as out-of order, and any packet that shows up more than 3 ms after it should have as a retransmission. This 3 ms value is arbitrary. If an out-of-order packet is delayed by more than 3 ms, it will be identified as a retransmission. A genuine retransmission should take one Round Trip Time, or a little more, after the original packet should have been seen.

If a packet has been correctly identified as a retransmission and there really has been packet loss somewhere along the path, the original packet might still be present in your trace file if the point of packet loss is downstream from your capture point. Because of this, retransmissions are not always preceded by tcp.analysis.lost_segments.

 

I have both client and server trace files. When I use the filters above, I see slight different values at client and server.

Yes, because packet loss occurred somewhere between the client and the server. If you capture on both the sender and the receiver, the capture at the sender should show all the original packets and all the retransmissions. The capture at the receiver will not show the original packets that were lost along the way, only the retransmissions.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe