Oh, I assumed that it was tracking the frames (based on a sequence
number or something) and only marking those that it saw more than once
as retransmissions. Just showing off my (complete) ignorance of 802.11
I guess ;-)
Jaap Keuter wrote:
Hi Jeff,
That depends if you want to assume that you've seen the originals of the
retransmitted frames or not. If you didn't you'll need them. If you did, like
in this case, you don't. Maybe there should be some sort of frame tracking in
there to match the operation of the endpoint toward it's protocol stack.
Thanx,
Jaap
Jeff Morriss wrote:
Ji Zhang wrote:
Dear all,
I’m currently using Wireshark v1.0.0 to analyse a Voice-over-802.11
session trace captured by the Airopeek Wifi sniffer. I extracted the RTP
session and tried to use the Wireshark RTP statistics tool to examine
the RTP packet loss rate. However, Wireshark did not give the actual RTP
packet loss statistics, instead, what it gave was the statistics of the
number of RTP packet retransmissions and regarded these retransmissions
as packet losses. Obviously RTP packet retransmissions only could happen
at the 802.11 layer, so this would rather be more like 802.11 packet
loss statistics.
Could anybody let me know if this is the expected behaviour? If not, is
there any patch/upgrade that fixes the issue? If yes unfortunately, is
there any way I may get the packet loss statistics at the actual RTP
layer using Wireshark? Much appreciated!
There is a preference for the 802.11 dissector
(Edit->Preferences->Protocols->IEEE 802.11): "Call subdissector for
retransmitted 802.11 frames". You might want to try turning that off
(the default appears to be on--should it be that way?).
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users