netdev - Re: kenel level packet capturing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EE86DB6.5050303@fox-it.com>
Date:	Wed, 14 Dec 2011 10:34:46 +0100
From:	Jasper Spaans <spaans@...-it.com>
To:	David Miller <davem@...emloft.net>
CC:	"raviraj.j1991@...il.com" <raviraj.j1991@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: kenel level packet capturing

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html