[Oisf-users] Losing a lot packets when suricata runs without detection modules

[C. L. Martinez]

On Wed, Dec 10, 2014 at 11:45 AM, Victor Julien <lists at inliniac.net> wrote:
> On 12/10/2014 11:33 AM, C. L. Martinez wrote:
>>  I am doing some tests running suricata without detection modules to
>> capture packets under FreeBSD 10.1 host.
>>
>>  To do these tests I am using 2.1beta2 and 2.0.4, and results are the
>> same: I loose between 65% and 90% of packets.
>>
>>  Current suricata.yaml used for both releases:
>>
>> %YAML 1.1
>> ---
>>
> [snip]
>>   - pcap-log:
>>       enabled: yes
>>       filename: snort.log
>>       limit: 2gb
>>       mode: sguil
>>       sguil-base-dir: /nsm/idpsuripcap01
>>       use-stream-depth: no
>
> Pcap logging in the 'sguil' mode is not very efficient. 2.1 includes a
> 'multi' mode but that won't work with sguil directly.
>
>> pcap:
>>   - interface: vtnet4
>>     #buffer-size: 4mb
>>     #checksum-checks: auto
>>     threads: 2
>
> Unless you have a special libpcap using 2 threads will result in getting
> the same packets twice.

uhmm .. I have doubts about this under FreeBSD, but changing to use
only 1 thread:

10/12/2014 -- 11:06:52 - <Info> - No packets with invalid checksum,
assuming checksum offloading is NOT used
10/12/2014 -- 11:08:05 - <Notice> - Signal Received.  Stopping engine.
10/12/2014 -- 11:08:05 - <Info> - 0 new flows, 0 established flows
were timed out, 0 flows in closed state
10/12/2014 -- 11:08:05 - <Info> - time elapsed 72.899s
10/12/2014 -- 11:08:06 - <Info> - 6513 flows processed
10/12/2014 -- 11:08:06 - <Info> - (RxPcapvtnet41) Packets 1342082,
bytes 1403483715
10/12/2014 -- 11:08:06 - <Info> - (RxPcapvtnet41) Pcap Total:2952706
Recv:1601341 Drop:1351365 (45.8%).
10/12/2014 -- 11:08:06 - <Info> - Stream TCP processed 1342183 TCP packets
10/12/2014 -- 11:08:06 - <Info> - host memory usage: 358144 bytes,
maximum: 16777216
10/12/2014 -- 11:08:06 - <Notice> - Stats for 'vtnet4':  pkts:
1342082, drop: 1316932 (98.13%), invalid chksum: 0


>
>> This is a 1GiB network.
>
> Do you mean gigabit instead?

Yes, sorry.