Dustin Spicuzza wrote:
So after reading the libpcap and kernel source, I see that this is
actually how its supposed to work. But it *seems* like it would be quite
nice if we could grab the interface driver drop statistics as well as
drops resulting from the capture buffer filling up.
I'm looking for a way to query the kernel about this number -- should I
bother submitting a patch if I can get it, or is the current behavior
more desired?
It appears that the only way to get this number is by looking at
/proc/stats/dev, so I added something that can parse it for the correct
interface, and get the drop stats from there. Since those are cumulative
over the boot time of the system, it stores a number and does
incremental updates of the number. It doesn't do this when not in
promiscuous mode however, since that doesn't make any sense.
It works for me, let me know what you think.
The current 'drop' count in libpcap is not intuitive, and frequently
arguably undercounts since it does not include 'rx buffer overflow' and
similar interface/OS specific packet loss. OTOH, the documentation is
quite clear about what it does count I think.
I would not recommend changing the definition or Linux implementation at
this point. It would change the behaviour for existing applications and
would only cause further confusion.
I think the current libpcap statistics interface is not very useful
because it is underspecified and varies too much between platforms.
Hopefully for pcap-ng (the portable packet capture library, not the file
format) we can get a better live statistics interface which is more
tightly defined and can conserve meaning across platforms.
E.g. we could track at least:
Packets received per interface
Packets dropped in hardware (due to packet errors)
Packets dropped in hardware (buffering/other reasons)
Packets dropped by driver
Packets dropped by kernel
Packets discarded by filter
Packets dropped by ring buffer (kernel-user space transport)
Packets read by application
and indicate which counters are available on the platform at run time.
Regards,
Stephen
--
-----------------------------------------------------------------------
Stephen Donnelly BCMS PhD email: s...@endace.com
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
-----------------------------------------------------------------------
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
