[Oisf-users] Packets stucked in Nfqueue when running inline

[Fernando Ortiz]

Thank you so much for your suggestion.

I compiled the last revision from git. The same problem. I followed your
steps:

>>    * Flush iptables rules (to block the packet counter in /proc)
>>    * Wait a few seconds for delivery of all packets

ips2 ~]# cat /proc/net/netfilter/nfnetlink_queue
    1    640     8 2 65535     0     0        166919  1
    2  -4290     9 2 65535     0     0        166920  1

>> * Get the number of packets queued from /proc (equal to last
       number before 1 in the proc file)

(RecvNFQ-Q1) Pkts 166919, Bytes 107024647, Errors 0
(RecvNFQ-Q2) Pkts 166920, Bytes 106693226, Errors 0

>>     * Stop suricata
>>    * Retrieve NFQ packets statistics in the log output (Pkts accepted
>>     %"PRIu32", dropped %"PRIu32", replaced %"PRIu32)

Q1->  Pkts accepted 166705, dropped 206, replaced 0
Q2->  Pkts accepted 166692, dropped 219, replaced 0

So, in Q1 166705 + 206 = 166911  = 166919 - 8
Same in Q2   166692 + 219 = 266911 = 166920 - 9

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.

I am not sure where to begin looking for this issue.

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.

Regards

2011/6/20 Eric Leblond <eric at regit.org>

> Hello,
>
> Le lundi 20 juin 2011 à 12:34 -0500, Fernando Ortiz a écrit :
> > Hello, I am running suricata 1.1beta2 (rev ) inline with this command:
> >
> >
> > suricata -c /etc/suricata/suricata.yaml -q1 -q2 -D
> >
> > Everything seems to work just fine, but when I check nfnetlink_queue,
> > i see there are some packets in queue waiting for verdict.
> >
> >
> > @ips2 ~]# cat /proc/net/netfilter/nfnetlink_queue
> >
> >     1  10893   555 2 65535     0     0 169915460  1
> >     2  -4282   552 2 65535     0     0 169915475  1
> >
> >
> > This happens most at night. Traffic is around 15 Mb/s with pikes at 20
> > Mb/s. The packets stucked are a few compared with the total number of
> > packets processed by Suricata. No problems reported by anyone in the
> > network.
>
> I've rarely looked at this proc file when using nfnetlink_queue. I sadly
> can not tell if it is frequent.
>
> What I can tell, is that suricata did not reach an nfnetlink overrun (it
> should have restarted the packet counter). Suricata does sequential
> reading and thus this is not a read problem (people are not
> complaining). One of the possibility is that some packets remained
> blocked in suricata.
>
> I see one possiblity to check this :
>      * Flush iptables rules (to block the packet counter in /proc)
>      * Wait a few seconds for delivery of all packets
>      * Get the number of packets queued from /proc (equal to last
>        number before 1 in the proc file)
>      * Stop suricata
>      * Retrieve NFQ packets statistics in the log output (Pkts accepted
>        %"PRIu32", dropped %"PRIu32", replaced %"PRIu32)
>
> With that we will be able to compare the number of queued packets to the
> number packet received and answer by suricata. If suricata has not seen
> the 555 packets queued, there is a problem before reaching suricata.
>
> > If I bypassed Suricata (iptables -F) packets are still there until I
> > kill suricata process.
>
> This part is normal, the packet are in a waiting stage and are freed
> when the listening process terminate (queue flush). Iptables can not be
> used to clear these packets.
>
> BR,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110620/ad4b596c/attachment-0002.html>