Subject: Re: kenel level packet capturing

From: Jasper Spaans <[email-masked]>
Date: Wed, 14 Dec 2011 10:34:46 +0100

On 13/12/11 19:36, David Miller wrote:
> We have decided to use PF_RING(a kernel module to capture packets) for
> the same due to the number of advantages.
> What "advantages"?  The AF_PACKET socket layer already upstream in the
> kernel supports every relevant performance feature PF_RING does, and
> then some.
Some documentation for fanout is one feature that would be nice. (How to
use it from userspace - after 5 minutes of googling, the first place
where I could find an example is in the suricata source code[1]).

Having not tested it in practice, so my assumptions about rxhash might
be untrue: is there an option to override the NIC rxhash
implementations? if you are doing packet capturing, you will probably
see traffic in both directions, so hashing on the address-tuples of both
directions makes sense (or else both half-streams of tcp packets might
end up being sent to different sockets.

It seems hardware vendors are focussed on only hashing the senders
address, which does make sense if you're building a
fileserver/webserver/whatever.

We ended up using atrocious bpfs like "((tcp[0:2] & 1) == (tcp[2:2] &
1)) and tcp" to distribute packets over multiple sockets, and now our
bottleneck has shifted away from the capturing side of our application.

(Note to Raviraj: we're not using PF_RING because of stability issues -
it crashed our testing system one too many times.)

Cheers,
Jasper

[1]
https://redmine.openinfosecfoundation.org/embedded/suricata/source-af-packet_8c-source.html#l00516

-- 
 /\____/\   Ir. Jasper Spaans      
 \   (_)/   Fox-IT Experts in IT Security!
  \    X    T: +31-15-2847999
   \  / \   M: +31-6-41588725   
    \/      KvK Haaglanden 27301624