[Oisf-users] Fwd: af_packet, rhel7, and suricata

erik clark philosnef at gmail.com
Wed Dec 7 12:34:55 UTC 2016

Sorry, this didn't make it to the list. Forwarding.

My suricata.yaml is built off of:


Yes, I have already turned off all the offloading.

According to:


fanout does not work with RHEL7 kernels, even if you set the rx hash. In
this case, its the 3.10.0-327.36.1.el7 kernel. I have read several places
that this is the case. I have tried setting the hash with:

ethtool -X $iface hkey 6d:5a:6d:5a....

and also tried setting the rss queue to 1 with

-L $iface combined 1

Interestingly, this seems to "work" without setting the hash or stripping
the rss queues. However, since I know that fanout isn't working as is, I
believe something in Suricata is not going correctly. This is evinced by
the fact that Bro (also on the same box) has a trashed conn and weird log
because traffic is going out one worker and coming back in on a totally
different worker. Given what Suri does, this may not actually be an issue,
but what concerns me is that connection driven signatures will fail because
the worker used to start the sig is not the same as the one receiving
return traffic.

Hope this makes sense.

Per RedHat support:

The eb70db875 fix is included in upstream v4.7 so if you need this feature
at the cost of everything else, you could use ELRepo's kernel-ml package of
v4.7 or later. I tested their kernel-ml-4.8.12-1.el7.elrepo, recompiled the
go application, and the test passes fine.

Where eb70db875 is the kernel patch that resolves this issue. It MIGHT be
fixed in 7.4, but I will not know. Based on the response from RHEL, I think
it is safe to say that AF_PACKET does not work as expected with Suricata on
RHEL7 at this time.

On Wed, Dec 7, 2016 at 4:52 AM, Cr3a70r <sickgamep at gmail.com> wrote:

> What kernel you use ?
> Did you set ethtool -K ethX gro off lro off?
> Did you set suricata AF_PACKET threads to 1 explicitly ?
> Show us your uname -a and suricata.yaml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20161207/a79e1c00/attachment-0002.html>

More information about the Oisf-users mailing list