Project

General

Profile

Actions

Bug #1918

open

Incorrect packet stats in pcap and pf_ring capture modes

Added by Marko Stojanovic almost 6 years ago. Updated about 2 years ago.

Status:
Assigned
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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.

https://redmine.openinfosecfoundation.org/attachments/628/0001-Fix-for-silly-pcap-counters-mistake-made-by-me.-ps_r.patch

P.S. AF-Packet correctly reports 1M total received on the NIC and drop% is
correct, at least it looks ok.

Actions #1

Updated by Victor Julien almost 6 years ago

  • Description updated (diff)
  • Target version deleted (3.1.3)
Actions #2

Updated by Victor Julien over 5 years ago

  • Assignee set to OISF Dev
  • Target version set to 70
Actions #3

Updated by Victor Julien almost 5 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Eric Leblond

Eric can you check this?

Actions #4

Updated by Eric Leblond over 4 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.

Actions #5

Updated by Andreas Herz about 3 years ago

Is there even a proper solution to this with the ps_recv behaviour?

Actions #6

Updated by Victor Julien about 2 years ago

  • Target version changed from 70 to TBD
Actions

Also available in: Atom PDF