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

[Eric Leblond]

Hello,

On Mon, 2011-06-20 at 19:36 -0500, Fernando Ortiz wrote:
> 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. 

This is really weird, I will try to look at it.

> 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.

If packet are blocked, this is because Suricata has decided to block it.
If I remember correctly this can be due to bad checksum or things like
that.

BR,

> 
> 
> 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,
>         
> 
> 

-- 
Eric Leblond 
Blog: http://home.regit.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110621/bcf59963/attachment.bin