Thank you so much for your suggestion. <div><br></div><div>I compiled the last revision from git. The same problem. I followed your steps:</div><div><br></div><div>>> * Flush iptables rules (to block the packet counter in /proc)</div>
>> * Wait a few seconds for delivery of all packets<br> <div><div>ips2 ~]# cat /proc/net/netfilter/nfnetlink_queue </div><div> 1 640 8 2 65535 0 0 166919 1</div><div> 2 -4290 9 2 65535 0 0 166920 1</div>
<div><br></div><div>>> * Get the number of packets queued from /proc (equal to last<br> number before 1 in the proc file)</div><div><br></div><div>(RecvNFQ-Q1) Pkts 166919, Bytes 107024647, Errors 0</div><div>
(RecvNFQ-Q2) Pkts 166920, Bytes 106693226, Errors 0</div><div><br></div><div>>> * Stop suricata<br>>> * Retrieve NFQ packets statistics in the log output (Pkts accepted<br>>> %"PRIu32", dropped %"PRIu32", replaced %"PRIu32)</div>
<div><br></div><div>Q1-> Pkts accepted 166705, dropped 206, replaced 0</div><div>Q2-> Pkts accepted 166692, dropped 219, replaced 0</div><div><br></div><div>So, in Q1 166705 + 206 = 166911 = 166919 - 8 </div>Same in Q2 166692 + 219 = 266911 = 166920 - 9<br>
<div class="gmail_quote"><br></div><div class="gmail_quote">You are right, these 17 packets are not seen by suricata, therefore, no one make a verdict and they are stucked in the queues waiting for one.</div><div class="gmail_quote">
<br></div><div class="gmail_quote">I am not sure where to begin looking for this issue. </div><div class="gmail_quote"><br></div><div class="gmail_quote">Another question, is it normal those 425 dropped packets? Right now Suricata is receiving 10Mbps in average, I think less. But in the future they want me to install one that support more than 700 Mbps. But I am a little worry about those dropped packets and of course, the "stucked" ones.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Regards </div><div class="gmail_quote"><br></div><div class="gmail_quote">2011/6/20 Eric Leblond <span dir="ltr"><<a href="mailto:eric@regit.org">eric@regit.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello,<br>
<br>
Le lundi 20 juin 2011 à 12:34 -0500, Fernando Ortiz a écrit :<br>
<div class="im">> Hello, I am running suricata 1.1beta2 (rev ) inline with this command:<br>
><br>
><br>
> suricata -c /etc/suricata/suricata.yaml -q1 -q2 -D<br>
><br>
> Everything seems to work just fine, but when I check nfnetlink_queue,<br>
> i see there are some packets in queue waiting for verdict.<br>
><br>
><br>
> @ips2 ~]# cat /proc/net/netfilter/nfnetlink_queue<br>
><br>
> 1 10893 555 2 65535 0 0 169915460 1<br>
> 2 -4282 552 2 65535 0 0 169915475 1<br>
><br>
><br>
> This happens most at night. Traffic is around 15 Mb/s with pikes at 20<br>
> Mb/s. The packets stucked are a few compared with the total number of<br>
> packets processed by Suricata. No problems reported by anyone in the<br>
> network.<br>
<br>
</div>I've rarely looked at this proc file when using nfnetlink_queue. I sadly<br>
can not tell if it is frequent.<br>
<br>
What I can tell, is that suricata did not reach an nfnetlink overrun (it<br>
should have restarted the packet counter). Suricata does sequential<br>
reading and thus this is not a read problem (people are not<br>
complaining). One of the possibility is that some packets remained<br>
blocked in suricata.<br>
<br>
I see one possiblity to check this :<br>
* Flush iptables rules (to block the packet counter in /proc)<br>
* Wait a few seconds for delivery of all packets<br>
* Get the number of packets queued from /proc (equal to last<br>
number before 1 in the proc file)<br>
* Stop suricata<br>
* Retrieve NFQ packets statistics in the log output (Pkts accepted<br>
%"PRIu32", dropped %"PRIu32", replaced %"PRIu32)<br>
<br>
With that we will be able to compare the number of queued packets to the<br>
number packet received and answer by suricata. If suricata has not seen<br>
the 555 packets queued, there is a problem before reaching suricata.<br>
<div class="im"><br>
> If I bypassed Suricata (iptables -F) packets are still there until I<br>
> kill suricata process.<br>
<br>
</div>This part is normal, the packet are in a waiting stage and are freed<br>
when the listening process terminate (queue flush). Iptables can not be<br>
used to clear these packets.<br>
<br>
BR,<br>
<br>
</blockquote></div><br>
</div>