On 30.06.2011 10:47, Eric Dumazet wrote:
Le jeudi 30 juin 2011 à 10:20 +0400, Kuzin Andrey a écrit :
On 29.06.2011 14:08, Eric Dumazet wrote:
Le mercredi 29 juin 2011 à 11:55 +0200, Anders Nilsson Plymoth a écrit :
Hi Eric,
Thanks for your reply.
Yes, I am sure I set the verdict, as right now I do it on all packets
by default.
I will try upgrading and see if it works. Do you know if commit
c463ac972315a0 solves the problem you mentioned?
No, it doesnt solve the problem, only make things faster.
But if some packets are never dequeued (because something is wrong with
your program, failing to give verdict), they stay forever in the list
and each dequeue is slower since it has to go past these packets...
2.6.37 also contains commit 29b4433d991c88d86ca48a4c1cc33c671475be4b
(net: percpu net_device refcount) which helps a lot netfilter
queue/dequeue if your machine is SMP.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello.
I'am using NFQUEUE several years on our main network router, and problem
with packets stuck in the queue is still not resolved.
But in the past when i use libipq, it not have this problem. I try to
use simple program with ACCEPT verdict on all packets, and after some
time queue has packets without any verdict, result is large (and
increased) delays on every packet and waste CPU time.
I'am write patch for this, but it doesn't apply by any netfilter
developers. Today i'am not using any kernel without this NFQUEUE patch.
diff --git a/net/netfilter/nfnetlink_queue.c
b/net/netfilter/nfnetlink_queue.c
index 8c86011..74fc322 100644
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -169,17 +169,29 @@ __enqueue_entry(struct nfqnl_instance *queue,
struct nf_queue_entry *entry)
queue->queue_total++;
}
+#define NFQNL_TIMEOUT_ENTRY_DROP 20
+
static struct nf_queue_entry *
find_dequeue_entry(struct nfqnl_instance *queue, unsigned int id)
{
- struct nf_queue_entry *entry = NULL, *i;
+ struct nf_queue_entry *entry = NULL, *next, *i;
+ ktime_t kt = ktime_get_real();
spin_lock_bh(&queue->lock);
- list_for_each_entry(i,&queue->queue_list, list) {
+ list_for_each_entry_safe(i, next,&queue->queue_list, list) {
if (i->id == id) {
entry = i;
break;
+ } else {
+ struct timeval tv =
ktime_to_timeval(ktime_sub(kt, i->skb->tstamp));
+ if (tv.tv_sec> NFQNL_TIMEOUT_ENTRY_DROP) {
+ printk(KERN_ERR "nf_queue: drop
timeouted packet "
+ "(queue_num=%d seq_id=%d)\n",
queue->queue_num, i->id);
+ list_del(&i->list);
+ queue->queue_total--;
+ nf_reinject(i, NF_DROP);
+ }
}
}
You do realize we have to find out what happened to these packets, why
no verdict was given at all ?
Also, where skb->tstamp is set exactly ? This depends on
netstamp_needed ?
Every day netfilter code become more and more difficult to understand.
IPQ mechanism don't have
this problems, migration to NFQUEUE by simply modifications of function
names in original program
code led to these problems. I think it very hard to find this error in
netfilter code and may be sometimes
NFQUEUE will be rewritten from scratch to NGQUEUE (next generation queue) ;)
I wrote this patch as simply as possible (one-hour solution) to solve
the problem for the our paid services.
Early no one netfilter developer did not pay any attention to messages
about this problem.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
