On Feb 10, 2009, at 1:09 PM, Dani Camps wrote:
I am trying to do captures of a traffic RTP/UDP Video flow streamed
over a Wi-Fi network using wireshark. Basically I set my wireless
card into monitor mode and then I can see all the traffic over the
Wi-Fi interface (802.11 signaling) by running wireshark on the
interface.
In the attached file you can see the capture. As it can be seen in
the trace marked with red arrows the transmitted sequence numbers
are not contiguous which means that some frames are lost. Now, my
question is whether is there any way that I can get wireshark to
tell me if these packets are really lost:
-Is there a way to ask wireshark to report FCS errors on the
measured interface ?
If you mean "is there a way to ask Wireshark to get the FCS error
statistics from the wireless adapter driver", no, there's currently no
way to do that.
I don't *think* the driver will discard packets with a bad FCS, or
configure the adapter to do so, when you're in monitor mode, however.
Some drivers might, but that's arguably a bug, as if you're in monitor
mode you're presumably trying to look for network issues and would
*want* to see packets that are, for example, damaged before reception.
-Could I get a reading of the power that was received in the
interface during the moments when a packet should have been lost ?
I don't know whether any wireless adapters can supply a power
indication except for a received packet; it sounds as if you want to
be able to read the current received signal level at a given time,
regardless of whether a packet is being received or not, so as to see
whether there wasn't sufficient power at your adapter to receive the
packet.
-What other things could be happening? Maybe is a failure of
wireshark and the packet is actually there ?
It could be a failure of the packet capture path as a whole, yes.
That code path involves:
1) the network adapter itself (which, I guess, could be overwhelmed
by too much traffic, although I suspect that's not the most likely
problem);
2) the buffer pool maintained by the driver (which, if packets aren't
consumed fast enough by the driver and possibly the application, could
fill up and cause the adapter to discard packets);
3) the buffering in the general capture mechanism (as you say
"monitor mode", this is probably Linux, *BSD, or Mac OS X; if it's
Linux, it's probably a socket buffer for a PF_PACKET socket, otherwise
it's a BPF buffer; in either case, if packets aren't consumed fast
enough by the application, that buffer can fill up and cause the
capture mechanism to discard packets).
That could be due to Wireshark not picking up packets fast enough, or
due to something else running on the machine interfering with
Wireshark's ability to read packets and write them to the capture
file, or with the driver's being able to respond to interrupts fast
enough to pick up packets, etc..
In cases 1) and 2), I don't think any of the OSes mentioned report
packets dropped. In case 3), the OS *should* report that; it's not
recorded in pcap-format capture files, but it will, at least, show up
if you're doing the capture with tcpdump, dumpcap, or Wireshark:
for tcpdump, when you type ^C, it should report "{N} packets dropped
by kernel";
for dumpcap, when you type ^C, it should report "Packets dropped: {N}";
for Wireshark, in the status bar at the bottom, the second section of
the status bar should include "Dropped: {N}".
(TShark didn't appear to print any count; unless it omits the count
when it's 0, I'd call that a bug. I'll look into that.)
That number should reflect the number of packets dropped by BPF in
*BSD and Mac OS X. Whether it'll reflect that in Linux depends on
whether you have a recent enough kernel and a recent enough libpcap;
you *probably* do.
