[Guy Harris <gharris@xxxxxxxxx>]

Guy Harris wrote:

> ...OR "the OS's packet capture mechanism drops packets if the 
> application isn't reading packets fast enough so that packets arrive 
> faster than the application consumes them, and the packet capture 
> mechanism's internal buffer fills up, *BUT* that packet capture 
> mechanism doesn't count the number of packets dropped if that happens, 
> so that libpcap can't report that value to the application".  That's the 
> case on some OSes, such as those with older Linux kernels.

None of that, of course, has anything WLAN-specific about it, nor does 
the packet capture mechanism *always* lose some WLAN packets, so this 
isn't a case of "is it true that Ethereal doesn't capture all WLAN 
packets?", it's a case of "is it true that Ethereal - or any other 
packet capture application - might not capture all packets on a 
network?", and the answer to the latter question is "yes, it *might* not."

It might be that, if you're capturing, on a WLAN, traffic going between 
two *other* machines (i.e., passively capturing traffic, rather than 
recording the traffic to and from the machine running Ethereal), for 
whatever reason, a packet that the receiver on the machine to which the 
packet is being sent succeeds in receiving might not be received, or 
might be received in a damaged form (such that the CRC is incorrect), by 
the machine doing the capture.

If, for example, the machine doing the capture is further from the 
transmitting machine or access point than is the receiving machine, or 
if it's in a "radio shadow" so that signals don't reach it as well, it 
might not see, at the radio level, all the packets transmitted by the 
machines whose traffic is being captured.

If it truly doesn't receive some of those packets at all (i.e., the 
signal strength is too weak for the radio hardware to respond to), there 
might not be any statistics available from the WLAN adapter driver to 
indicate that this happened, as even the *adapter* might not know that 
happened (it'd just consider the packet as radio noise).

If they arrive corrupted (with a bad CRC), or as a scrambled 
transmission (if, for example, the signal is strong enough for the radio 
to receive it, but the sync portion at the beginning of the packet isn't 
received completely correctly), the adapter might report that to the 
driver, which might supply that statistic.  That statistic probably 
isn't directly supplied to libpcap, however, as most packet capture 
mechanisms don't have a way to supply that (BPF doesn't, for example, at 
least on most OSes), and libpcap currently doesn't attempt to directly 
query the adapter driver for those statistics.  Ethereal only reports 
what libpcap supplies it.

So, in those cases, a WLAN packet might not be captured by a passive 
"third-party" capture even if the packet is successfully received by the 
station to which it's transmitted, and Ethereal won't be able to report 
the number of times that happens.

However, if you're running Ethereal on one of the machines whose traffic 
you're capturing - for example, in Rupesh's original scenario, if he 
runs it on the FTP client or server - that won't happen; obviously, if 
the packet is received by that machine, it's been captured by that machine.

That does *NOT* mean that Ethereal will necessarily see it; it might be 
dropped by the capture mechanism because its buffer isn't being emptied 
fast enough by Ethereal.