The AF_Packet in 4.4 and onward has undergone a major redesign and rewrite.
In order to make it more generic and correctly support Vlans, GRE tunnels, IPv6, and so on, the hash function has been generalized and is not symmetric anymore.
This affacts the af_packet capture plugin.
For kernel version 4.2, the following function was used
static inline u32 __flow_hash_from_keys(struct flow_keys *keys)
/* get a consistent hash (same value on both flow directions) */
In 4.4 it's jhash2, which is not symmetric. This results in splitted connections.
static __always_inline u32 __flow_hash_words(const u32 *words, u32 length, u32 keyval)
return jhash2(words, length, keyval);
I have tested this on 4.2, then upgraded to 4.4, observed lots of SAD connections, went back to 4.2.
This seems to clarify this design decision
After consulting Suricata developers (thank you, Regit!!) seems like there's a new way to achieve consistent hashing. This method must be implemented for kernels >= 4.4 (maybe others, too).
eBPF fanout mode, so you write a filter and it af_packet respects hashing from it.
What's the plan here? Anything to do for 2.5?
Seems it was finally recognized as a kernel bug and fixed: http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=eb70db8756717b90c01ccc765fdefc4dd969fc74
That is a great news!!
I strongly recommend waiting for a new kernel to appear in distributions people use, such as Ubuntu. When I does, I will verify things work as they should and we can close that and add a documentation which versions should be avoided.
Suricata, on the other hand, solved it with eBPF.
That's fantastic. I'll open a bug with RedHat to get it back ported to the
3.10 EL7 kernel. Should be relatively straightforward with these
changelogs. That will trickle down to distros like CentOS, Oracle and
On Thu, Jul 28, 2016, 22:26 Michal Purzynski (JIRA) <
Sounds like there's nothing for us to do here, so closing.