Date: Mon, 14 Dec 2015 16:38:00 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 205320] net: incorrect BPF stats Message-ID: <bug-205320-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205320 Bug ID: 205320 Summary: net: incorrect BPF stats Product: Base System Version: 10.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: elofu17@hotmail.com In e.g. 'netstat -B', the Recv column show the total amount of packets rece= ived 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 =C2=A0=C2=A0Pid 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 count= er. 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-205320-8>