In e.g. 'netstat -B', the Recv column show the total amount of packets received by BPF. Quite often, this value is *less* than the Match value. This should be impossible! Example: I send 2000000 packets to ix1 while running tcpdump on it. After the 2000000 packets are sent, I run: # netstat -B Pid Netif Flags Recv Drop Match Sblen Hblen Command 25553 bridge0 p--s--- 1996862 0 2000000 0 0 tcpdump 1996862 is less than 2000000. I reported this to the freebsd-net maillist where Alexander V. Chernikov replied that "Recv" is read from d->bd_rcount, which is not a per-cpu counter. Also it is incremented in an unlocked state. "Match" on the other hand increases when filter returned a match condition, and use a (w)locked bpf descriptor, so this one is accurate. All sniffing tools that report some form of BPF statistics (snort, suricata, tcpdump, tshark, etc) give very confusing and inaccurate values. This need to be fixed. /Elof
Any comments to this bug? It's very bad (and confusing) when the statistics from tools show weird/incorrect values. Especially in tools like snort, which calculate the percentage of drops/missing/unhandled packets. There one can see negative percentages or that the percentage of analyzed packets is more than 100%, etc.
A commit references this bug: Author: melifaro Date: Tue Mar 20 22:57:06 UTC 2018 New revision: 331275 URL: https://svnweb.freebsd.org/changeset/base/331275 Log: Use count(9) api for the bpf(4) statistics. Currently each bfp descriptor uses u64 variables to maintain its counters. On interfaces with high packet rate this leads to unnecessary contention and inaccurate reporting. PR: kern/205320 Reported by: elofu17 at hotmail.com MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D14726 Changes: head/sys/net/bpf.c head/sys/net/bpfdesc.h
Alexander, can this PR be closed or is there work pending? Thanks