<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">After talking a bit more with Fatema, we learned there might be a problem with the kernel version on that server.<div><br></div><div>Victor's patch shows 30% of packets sent to a wrong thread. Bro and Snort use pf_ring.</div><div><br></div><div>Suggestions would be to use hardware hashing and af_packet in QM mode. Note - the XDP part is not needed for this setup to work.</div><div><br></div><div><font color="#1155cc"><u><a href="https://github.com/pevma/SEPTun-Mark-II/blob/master/SEPTun-Mark-II.rst#setup-symmetric-hashing-on-the-nic">https://github.com/pevma/SEPTun-Mark-II/blob/master/SEPTun-Mark-II.rst#setup-symmetric-hashing-on-the-nic</a></u></font><br></div><div><font color="#1155cc"><u><br></u></font></div>just do the symmetric hashing part and then change Suricata's configuration to use cluster_qm</div><div dir="ltr"><br></div><div dir="ltr"><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:16px;padding:16px;overflow:auto;line-height:1.45;background-color:rgb(246,248,250);border-radius:3px;color:rgb(36,41,46)">  cluster-type: cluster_qm # symmetric hashing  is a must!
</pre><br class="gmail-Apple-interchange-newline"></div><div dir="ltr"><br></div><div dir="ltr"><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 5, 2018 at 2:20 PM Michał Purzyński <<a href="mailto:michalpurzynski1@gmail.com">michalpurzynski1@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How about we make Suricata write us a pcap in afpacket workers mode? I’m pretty sure a rule can do that.<br>
<br>
> On Oct 5, 2018, at 8:17 PM, fatema bannatwala <<a href="mailto:fatema.bannatwala@gmail.com" target="_blank">fatema.bannatwala@gmail.com</a>> wrote:<br>
> <br>
> Changing $HOME_NET to any in sid 2022813 didn't help though, still not getting that alert fired.<br>
> One difference I had in suricata.yaml when running in offline pcap reading mode was, I set runmode to "single", while when suricata runs in packet sniffing mode it's set to "workers".<br>
> <br>
> I tried to set it to "runmode:single" while on interface sniffing mode but was hit by ~60% capture loss, which makes sense as single threaded suricata can't handle the traffic flowing through the interface. <br>
> <br>
> The fact that alerts are fired when in offline single threaded mode and same alerts are not fired when online packet sniffing multi-threaded mode, makes me think it has to do with multi-threading vs single threaded mode and how "workers" are capturing packets.<br>
> <br>
> I will keep looking.<br>
> <br>
> (The good thing is that Interrupt/IRQ pinning has helped to reduce capture loss to 0%)<br>
> <br>
> Thanks,<br>
> Fatema <br>
> <br>
> <br>
> _______________________________________________<br>
> Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundation.org</a><br>
> Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/support/</a><br>
> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
> <br>
> Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
> Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a><br>
</blockquote></div>