FatRiSha wrote:
So,.. Linux kernel 2.2 and above already used kernel filtering, right?
They already supported kernel filtering.
and there's no BPF in Linux at all, right?
There's no BPF in the sense of a raw packet capture and sending metod that behaves the way BPF behaves on BSD.
There *is*, however, an interpreter for the same fake "machine language" for packet filter expressions that the BSD BPF mechanism uses.
Another question: 'pcap_stats' give two output: Packet Received and Packet Drop.
If I want to measure how many 'packet X' (using filtering) passed in my Router, and i'm using
a sample program like 'tethereal' and report like this:
1000 packets captured
100 packets dropped
So the total 'packet X' passed was 1100 packets, right??
Well, the first thing to note is that "1000 packets captured" reports that Tethereal actually got 1000 packets from libpcap and wrote them to a file or printed them; it is *NOT* reporting the "ps_recv" statistic from "pcap_stats()".
That's because the "ps_recv" statistic, on some platforms, reports the number of packets that were received by the kernel's filtering mechanism, or that passed the kernel's filtering mechanism, not the number that were read from the kernel's filtering mechanism by libpcap or that were supplied to the application by libpcap.
When you stop a capture, there might be packets that are buffered in the kernel's packet capture mechanism, or in libpcap, that have not been read and processed by the application; those packets will be counted in ps_recv, but will *not* be counted in the "N packets captured" statistic.
Tcpdump used to report only the ps_recv statistic, but that confused people - it might have said "1507 packets received by filter", but the capture file might have had only 1498 packets. Tcpdump now reports "N packets captured", where N is the number of packets that were read by tcpdump from libpcap and processed by tcpdump (printed or saved to a file). It also reports the statistics from pcap_stats().
So "1000 packets captured" means, in Tethereal and tcpdump, "1000 packets read from libpcap and processed".
What "100 packets dropped" means is that, of all the packets supplied to the kernel's packet capture mechanism that passed the filter, 100 of them were dropped because there wasn't enough room in the kernel's buffer for them; this means that packets aren't being read from the kernel's capture mechanism fast enough by the application.
If you want to know how many packets passed the filter:
That number is not available on any BSD (including Mac OS X) other than recent versions of NetBSD - ps_recv counts the number of packets that were run through the packet filter, *not* the number that passed the filter. In recent versions of NetBSD, the ioctl used to implement pcap_stats() also returns a count of the number of packets that passed the filter - regardless of whether it was then dropped because the buffer was full or not - but libpcap doesn't support that. (The libpcap API for getting statistics needs to be changed so that it can add new statistics without breaking binary compatibility - and so that it can specify which statistics are being supplied, so that if some statistics, such as the count of dropped packets, are unavailable, the caller will know that it's not being supplied.)
On Linux, pre-2.4 kernels supply no counts of dropped packets. The number reported is always 0, even if packets *were* dropped. They also supply no count of received packets; the number of packets supplied to the application by libpcap is returned. 2.4 and later kernels do keep statistics; ps_recv is the number of packets that passed the filter, and ps_drop is the number of those packets that were dropped, so ps_recv includes packets counted in ps_drop, and the number of packets that passed the filter is just ps_recv. (Note that the application won't necessarily have seen all those packets.)
On Digital/Tru64 UNIX, ps_recv counts packets that passed the filter but doesn't count dropped packets; this is arguably a bug, as it's different from the way BSD and Linux work, so it will probably be fixed in a future release.
Look at comments in front of the stats routines in all the pcap-*.c files in the libpcap source for details on those and other operating systems.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
