Keep track of lost packets as reported by pcap_stats
On my machine, if I generate the following IPv6 flood:
ip -6 neigh add fe80::1234 dev eth0 lladdr 00:11:22:33:44:55
nc -6 -u fe80::1234%eth0 1234 < /dev/zero
The traffic reported by iftop is much less than the reality, as iftop
can't read packets off pcap fast enough. This patch only demonstrate
the problem, I haven't started to dig into the cause yet.
When packets that are too short to be valid IP packets happen to start
with 0x45 or 0x60, iftop will still try to read source and destination
addresses, which will usually just be random garbage.
Note the assumption about what libpcap guarantees in the comments to
handle_ip_packet():
* It is assumed that the snaplen (currently hard-coded to 1000) is
* big enough to always capture the IP header past the L2 encap, and
* that pcap never truncates the packet to less than snaplen; in
* other words, that pcaphdr->caplen = MIN(pcaphdr->len, snaplen).
Frédéric Perrin [Tue, 31 Mar 2015 14:54:19 +0000 (15:54 +0100)]
Do traffic accounting in pps
Add a "-u unit" CLI option, as well as a "bandwidth-unit" configuration file
option. With "-u packets", traffic is accounted using packets per second; the
other options are "-u bits" and "-u bytes".
"-B" is still recognized as synonym to "-u bytes".
The default is "-u bits", keeping the current behaviour of iftop (everything
is in bits/s, except the cumulative totals).