Wireshark-users: Re: [Wireshark-users] packets captured and received by filter

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 [email protected]

(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.