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.
