<br><br><div class="gmail_quote">On Mon, Aug 23, 2010 at 3:52 AM, Victor Julien <span dir="ltr"><<a href="mailto:victor@inliniac.net">victor@inliniac.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
m wrote:<br>
>> The main issue with nfqueue is performance. As discussed with Victor<br>
>> Julien once, it is not possible to exceed a certain number of packets<br>
>> per second (even if hardware is improved). This limit is quiet annoying<br>
>> and a better/faster queuing mechanism has to be developped to fix this<br>
>> issue.<br>
><br>
> No, the main issue with nfqueue is that it is a terminating target and<br>
> diverts the packet to the next table, instead of going to the next rule<br>
> in the table.<br>
> The kernel can buffer packets pretty fast, that's it's specialty.<br>
<br>
Moving Suricata into the kernel seems like the wrong solution for fixing<br>
that issue. Writing a new and better queuing mechanism would make more<br>
sense.<br>
<br>
Cheers,<br>
Victor<br>
<br></blockquote><div><br></div><div>Victor is 100% right. If you're using Netfilter, you could write your own module to put packets into user space, and forward (or drop them) as needed. Or hire Patrick McHardy to do it for you 8-).   Nfqueueing is a general purpose mechanism to allow multiple queues of packets to user space processes. Performance was secondary to functionality.</div>
<div><br></div><div>If you're looking for maximum throughput, it would be better to hook the packet either at the driver or in the bridge module, and avoid Netfilter completely, at least for IPS mode. Development makes for exciting kernel crashing... </div>
<div><br></div><div>Running Suricata in the kernel can be done, but I doubt that it's worth the effort.  32 bit kernels need not apply; there's not enough low mem (typically) to run Suricata in with any kind of rule set (as I believe Victor has already pointed out). 64 bit kernels, now, that's a different story.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Dave</div></div><br>-- <br>"Of course, someone who knows more about this will correct me if I'm<br>wrong, and someone who knows less will correct me if I'm right." <br>
David Palmer (<a href="mailto:palmer@tybalt.caltech.edu">palmer@tybalt.caltech.edu</a>)<br><br>