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