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]

Date:	Wed, 14 Dec 2011 10:56:56 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jasper Spaans <spaans@...-it.com>
Cc:	David Miller <davem@...emloft.net>,
	"raviraj.j1991@...il.com" <raviraj.j1991@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: kenel level packet capturing

Le mercredi 14 décembre 2011 à 10:34 +0100, Jasper Spaans a écrit :
> 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.
> 

Disabling NIC rxhash is possible :

# ethtool -k eth2 | grep receive-hashing
receive-hashing: on
# ethtool -K eth2 rxhash off
# ethtool -k eth2 | grep receive-hashing
receive-hashing: off

> 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.

If you want to distribute load on tcp sockets, you can take a look at
various tricks documented in Documentation/networking/scaling.txt

(RPS, RFS, ...)


> (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
> 




--
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