Re: packets captured and received by filter

[Guy Harris <guy () alum mit edu>]

On Nov 2, 2009, at 9:26 AM, George Nychis wrote:

> This is a tcpdump specific question, sorry that it is not directly a  
> wireshark question.  I could not find a user's mailing list for  
> tcpdump.

It's tcpdump-workers () tcpdump org.

(Not the best name, perhaps - think of tcpdump-workers as the union of  
four mailing lists that, if they existed as separate lists, would be  
called something such as tcpdump-users, tcpdump-developers, libpcap- 
users, and libpcap-developers; it's not *just* a user's mailing list  
for tcpdump, it's also a developer's list for tcpdump and a user's and  
developer's list for libpcap.  "workers" might date back to a time  
when it was mainly used by tcpdump developers, including users who  
were also developers.)

> I am capturing wireless traffic on ath0 as follows:

 From "ath0", I infer that this is on some flavor of *BSD.  Is that  
correct?  (I'll assume so; the answers below are for BPF as it exists  
on *BSD and Mac OS X.)

> sudo tcpdump -s 0 -i ath0 -w /tmp/tmp.pcap
>
> When finished, I see:
> 19431 packets captured
> 38863 packets received by filter
> 0 packets dropped by kernel
>
> Why is there a gap between packets received by the filter, and  
> captured?  Can the machine not keep up with the capture?

No - if it couldn't keep up with the capture, you wouldn't be seeing  
"0 packets dropped by kernel", there'd be a non-zero number there.

At least in newer versions of tcpdump, the "packets captured" number  
is a number that's incremented every time tcpdump sees a packet, so it  
counts packets that tcpdump reads from libpcap and thus that libpcap  
reads from BPF and supplies to tcpdump.

The "packets received by filter" number is the "ps_recv" number from a  
call to pcap_stats(); with BPF, that's the bs_recv number from the  
BIOCGSTATS ioctl.  That count includes all packets that were handed to  
BPF; those packets might still be in a buffer that hasn't yet been  
read by libpcap (and thus not handed to tcpdump), or might be in a  
buffer that's been read by libpcap but not yet handed to tcpdump, so  
it can count packets that aren't reported as "captured".

It's interesting that {packets captured}*2 + 1 = {packets received by  
filter}.  If the packets are mostly beacons, so that they're mostly  
the same size, and small, and you're not running for a long period of  
time, it might be that this is a consequence of the double-buffering  
done by BPF; if, for example, the "store buffer" of packets fills up  
before the timeout given to BPF (1 second, in the case of tcpdump)  
expires, and that store buffer then becomes the "hold buffer" and is  
handed to libpcap by BPF, and, while libpcap and tcpdump process that  
one buffer, the other store buffer then fills up again, with an equal  
number of packets or with one more or less packet, and you stop before  
that buffer is read and handed to tcpdump, that could give you results  
like that.  However, it's still a little odd that it's *exactly* 2*N+1.
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe