Linux Netfilter discussions
 help / color / mirror / Atom feed
* nfqueue stuck on queue length >299
@ 2011-10-13 13:37 abirvalg
  0 siblings, 0 replies; 6+ messages in thread
From: abirvalg @ 2011-10-13 13:37 UTC (permalink / raw)
  To: netfilter

Sorry, I have to retract my previos statement.
The reason why it lifted the bar to 359 is because I changed the amount of data to copy to NFQUEUE to 
nfq_set_mode ( globalqh_repeat, NFQNL_COPY_META, 0 )
whereas the 299 was hit when I had
nfq_set_mode ( globalqh_input, NFQNL_COPY_PACKET, 40 )
Of course this shows that some NFQUEUEs buffer get filled.
But my issue is not how to increase the size of this buffer, my question is:
Why after the buffer reaches its limit, it refuses to shrink and get stuck.

Am I overlooking something or is this a bug worth reporting to the developers.
Or could somebody write a simple app and confirm my finding on their machine?


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: nfqueue stuck on queue length >299
@ 2011-10-13 14:05 aletum
  0 siblings, 0 replies; 6+ messages in thread
From: aletum @ 2011-10-13 14:05 UTC (permalink / raw)
  To: netfilter

On 10/13/2011 03:27 PM, abirvalg@lavabit.com wrote:
> On 10/13/2011 02:29 PM, abirvalg@lavabit.com wrote:  
>> In my app one thread sends packets to NFQUEUE and another thread processes that \
>> NFQUEUE at the rate of 10 packets per second. I watch the state of NFQUEUEs using \
>> watch -n 1 'cat /proc/netnetfilter/nfnetlink_queue' I noticed that if I \
>> nfq_set_queue_maxlen to 299, then when the queue fills up to 299 (3rd column), the \
>> overflow gets dropped. As soon as new packets cease to arrive, dequeuing begins at \
>> the rate of 10 per second until the 3rd columnn reaches 0. All as expected. 
>> But as soon as I set NFQUEUE maxlen to 300, the following happens - the overflow \
>> gets dropped; but when I stop generating new packets, no dequeuing is taking place, \
>> the 3rd column seems to be stuck on 299 and from then on packets for that NFQUEUE \
>> don't get queued anymore but are dropped instead. The NFQUEUE still processes \
>> packets at the rate of 10 per second, but instead of queuing the overflow, it \
>> simply drops it. 
>> Is this a bug or a feature? Sure seems like a bug to me.  
>   
>> Are you using some form of lock (like a mutex) to protect your nfq
>> calls? In my experience you need those.  
> 
> Thank you for you suggestion. It didn't work, alhough I held my breath for a second.
> I inserted
> pthread_mutex_lock ( &nfqrepeat_mutex ) 
> at the start of the queue handler and
> pthread_mutex_unlock ( &nfqrepeat_mutex )
> right before return 0;
> This time around the 3rd column did overcome the vicious 299 figure but stuck on 359 and exhibited the same begaviour as I described above when it would get stuck on 299.
> 
> Some kind of voodoo going on?  

>Did you protect the verdict call by the same mutex? Thats what we do in
>suricata.

I have :
        nfq_set_verdict ( ( struct nfq_q_handle * ) qh, id, NF_REPEAT, 0, NULL );
	pthread_mutex_unlock ( &nfqrepeat_mutex );
	return 0;

So, yes verdict is covered by mutex.


^ permalink raw reply	[flat|nested] 6+ messages in thread
* nfqueue stuck on queue length >299
@ 2011-10-13 13:27 abirvalg
  2011-10-13 10:50 ` Victor Julien
  0 siblings, 1 reply; 6+ messages in thread
From: abirvalg @ 2011-10-13 13:27 UTC (permalink / raw)
  To: netfilter

On 10/13/2011 02:29 PM, abirvalg@lavabit.com wrote:
> In my app one thread sends packets to NFQUEUE and another thread processes that \
> NFQUEUE at the rate of 10 packets per second. I watch the state of NFQUEUEs using \
> watch -n 1 'cat /proc/netnetfilter/nfnetlink_queue' I noticed that if I \
> nfq_set_queue_maxlen to 299, then when the queue fills up to 299 (3rd column), the \
> overflow gets dropped. As soon as new packets cease to arrive, dequeuing begins at \
> the rate of 10 per second until the 3rd columnn reaches 0. All as expected. 
> But as soon as I set NFQUEUE maxlen to 300, the following happens - the overflow \
> gets dropped; but when I stop generating new packets, no dequeuing is taking place, \
> the 3rd column seems to be stuck on 299 and from then on packets for that NFQUEUE \
> don't get queued anymore but are dropped instead. The NFQUEUE still processes \
> packets at the rate of 10 per second, but instead of queuing the overflow, it \
> simply drops it. 
> Is this a bug or a feature? Sure seems like a bug to me.

>Are you using some form of lock (like a mutex) to protect your nfq
>calls? In my experience you need those.

Thank you for you suggestion. It didn't work, alhough I held my breath for a second.
I inserted
pthread_mutex_lock ( &nfqrepeat_mutex ) 
at the start of the queue handler and
pthread_mutex_unlock ( &nfqrepeat_mutex )
right before return 0;
This time around the 3rd column did overcome the vicious 299 figure but stuck on 359 and exhibited the same begaviour as I described above when it would get stuck on 299.

Some kind of voodoo going on?


^ permalink raw reply	[flat|nested] 6+ messages in thread
* nfqueue stuck on queue length >299
@ 2011-10-13 12:29 abirvalg
  2011-10-13  9:35 ` Victor Julien
  0 siblings, 1 reply; 6+ messages in thread
From: abirvalg @ 2011-10-13 12:29 UTC (permalink / raw)
  To: netfilter

In my app one thread sends packets to NFQUEUE and another thread processes that NFQUEUE at the rate of 10 packets per second.
I watch the state of NFQUEUEs using watch -n 1 'cat /proc/netnetfilter/nfnetlink_queue'
I noticed that if I nfq_set_queue_maxlen to 299, then when the queue fills up to 299 (3rd column), the overflow gets dropped. As soon as new packets cease to arrive, dequeuing begins at the rate of 10 per second until the 3rd columnn reaches 0. All as expected.

But as soon as I set NFQUEUE maxlen to 300, the following happens - the overflow gets dropped; but when I stop generating new packets, no dequeuing is taking place, the 3rd column seems to be stuck on 299 and from then on packets for that NFQUEUE don't get queued anymore but are dropped instead. The NFQUEUE still processes packets at the rate of 10 per second, but instead of queuing the overflow, it simply drops it.

Is this a bug or a feature? Sure seems like a bug to me.


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-10-13 14:05 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-13 13:37 nfqueue stuck on queue length >299 abirvalg
  -- strict thread matches above, loose matches on Subject: below --
2011-10-13 14:05 aletum
2011-10-13 13:27 abirvalg
2011-10-13 10:50 ` Victor Julien
2011-10-13 12:29 abirvalg
2011-10-13  9:35 ` Victor Julien

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox