Bug #1918
openIncorrect packet stats in pcap and pf_ring capture modes
Description
In high networking load i noticed that packet dropped stats went above 100%.
I get stats like this one in example:
pkts : 250833
drop : 749860
drop % : 298,95%
What got me suspicious since i sent exactly 1M packets to Suricata, and the
sum of those 2 numbers is around that 1M.
Both pcap and pf_ring modes are affected.
Looking through source-pcap.c file, in lines 661-663 i found next formula :
SCLogInfo("(%s) Pcap Total:%" PRIu64 " Recv:%" PRIu64 " Drop:%" PRIu64 " (
%02.1f%%).", tv->name,
(uint64_t)pcap_s.ps_recv, (uint64_t)pcap_s.ps_recv - (uint64_t)pcap_s.
ps_drop, (uint64_t)pcap_s.ps_drop,
(((float)(uint64_t)pcap_s.ps_drop)/(float)(uint64_t)pcap_s.ps_recv)*100);
Lurking some more i found this old patch from 2011 that I think solves
those stats issues where the drop% is calculated on the sum of those 2
values,yet here is not implemented.
P.S. AF-Packet correctly reports 1M total received on the NIC and drop% is
correct, at least it looks ok.
Updated by Victor Julien over 7 years ago
- Description updated (diff)
- Target version deleted (
3.1.3)
Updated by Victor Julien about 7 years ago
- Assignee set to OISF Dev
- Target version set to 70
Updated by Victor Julien over 6 years ago
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Eric Leblond
Eric can you check this?
Updated by Eric Leblond about 6 years ago
The pcap_stats page is a bit explaining in a complicated manner that we don't know what is counted:
The statistics do not behave the same way on all platforms. ps_recv might count packets whether they passed any filter set with pcap_setfilter(3PCAP) or not, or it might count only packets that pass the filter. It also might, or might not, count packets dropped because there was no room in the operating system's buffer when they arrived. ps_drop is not available on all platforms; it is zero on platforms where it's not available. If packet filtering is done in libpcap, rather than in the operating system, it would count packets that don't pass the filter. Both ps_recv and ps_drop might, or might not, count packets not yet read from the operating system and thus not yet seen by the application. ps_ifdrop might, or might not, be implemented; if it's zero, that might mean that no packets were dropped by the interface, or it might mean that the statistic is unavailable, so it should not be treated as an indication that the interface did not drop any packets.
Most interesting extract is about ps_recv:
It also might, or might not, count packets dropped
Regarding the patch pointed out in the issue, it is already applied.
Only we to deal with that would be not to output the percentage so the provided numbers will not be wrong even if they can have different meaning.
Updated by Andreas Herz almost 5 years ago
Is there even a proper solution to this with the ps_recv behaviour?
Updated by Victor Julien over 1 year ago
- Status changed from Assigned to New
- Assignee changed from Eric Leblond to Community Ticket