Bug 205320

Summary: net: incorrect BPF stats
Product: Base System Reporter: elofu17
Component: kernAssignee: Alexander V. Chernikov <melifaro>
Status: Closed FIXED    
Severity: Affects Many People CC: gonzo, melifaro
Priority: ---    
Version: 10.1-RELEASE   
Hardware: Any   
OS: Any   

Description elofu17 2015-12-14 16:38:00 UTC 
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
Comment 1 elofu17 2016-03-14 16:10:31 UTC 
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.
Comment 2 commit-hook freebsd_committer freebsd_triage 2018-03-20 22:57:36 UTC 
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
Comment 3 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-21 18:03:18 UTC 
Alexander, can this PR be closed or is there work pending?

Thanks