netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Anton VG <anton.vazir@gmail.com>
Cc: netfilter-devel <netfilter-devel@vger.kernel.org>,
	Vitaly Bodzhgua <vitaly@eastera.tj>
Subject: Re: (nfnl_talk: recvmsg over-run) and (nf_queue: full at 1024 	entries, dropping packets(s). Dropped: 582) - bug or just some defaults 	increase required?
Date: Tue, 17 Feb 2009 18:15:36 +0100	[thread overview]
Message-ID: <499AF0B8.5060202@netfilter.org> (raw)
In-Reply-To: <c4b050a10902170858j698c32c3ye6c58682911c59eb@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Anton VG wrote:
> Pablo,
> A little update, just tried non-patched variant with blocking, the
> only difference is - it generated ERROR only once and hanged (waiting
> for data)
> Any update from you?

Yes, I got a trace of the problem (with blocking behaviour):

userspace                       kernelspace
create queue (seq=x) --->
add iptables rule    --->
                     <--- (seq=0) packet sent
verdict (seq=x+1)    --->
                     <--- (seq=0) packet sent
verdict (seq=x+2)    --->
                     <--- (seq=x) ACK message

Then, it hits EILSEQ. The patch attached applies to libnfnetlink, it
sets the sequence number for messages if we expect to receive an answer
from kernelspace. With it, I can hit ENOBUFS (that's normal), but not
EILSEQ anymore.

With non-blocking behaviour, you may still hit EILSEQ (even with the
patch applied) since the current API does not allow non-blocking queue
creation.

BTW, why don't open one socket handler per queue? That will reduce the
chances to hit ENOBUFS. Now the problem for you would be that you'll
have a lot of descriptors in userspace to handle (probably select() is
not the best choice anymore) but more netlink bandwidth in return.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 642 bytes --]

diff --git a/src/libnfnetlink.c b/src/libnfnetlink.c
index d4212f9..5cfe2f5 100644
--- a/src/libnfnetlink.c
+++ b/src/libnfnetlink.c
@@ -418,7 +418,11 @@ void nfnl_fill_hdr(struct nfnl_subsys_handle *ssh,
 	nlh->nlmsg_type = (ssh->subsys_id<<8)|msg_type;
 	nlh->nlmsg_flags = msg_flags;
 	nlh->nlmsg_pid = 0;
-	nlh->nlmsg_seq = ++ssh->nfnlh->seq;
+	/* set sequence number if we expect an answer from kernelspace */
+	if (msg_flags & (NLM_F_ACK | NLM_F_ECHO | NLM_F_DUMP))
+		nlh->nlmsg_seq = ++ssh->nfnlh->seq;
+	else
+		nlh->nlmsg_seq = 0;
 
 	/* check for wraparounds: assume that seqnum 0 is only used by events */
 	if (!ssh->nfnlh->seq)

  reply	other threads:[~2009-02-17 17:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-06 18:14 (nfnl_talk: recvmsg over-run) and (nf_queue: full at 1024 entries, dropping packets(s). Dropped: 582) - bug or just some defaults increase required? Anton VG
2009-02-08  1:34 ` Pablo Neira Ayuso
2009-02-09 10:56   ` Anton
2009-02-09 11:20     ` Pablo Neira Ayuso
2009-02-11  8:48       ` Anton
     [not found]       ` <49928B62.1090600@netfilter.org>
2009-02-11 12:26         ` Anton VG
2009-02-11 16:41           ` Pablo Neira Ayuso
2009-02-12 10:45             ` Anton
2009-02-12 12:43               ` Pablo Neira Ayuso
2009-02-14  9:03                 ` Anton
2009-02-14 17:13               ` Pablo Neira Ayuso
2009-02-16 13:19                 ` Anton
2009-02-16 13:42                   ` Pablo Neira Ayuso
2009-02-16 14:38                     ` Anton VG
2009-02-16 15:23                       ` Pablo Neira Ayuso
2009-02-16 15:33                         ` Anton VG
2009-02-16 15:41                           ` Anton VG
2009-02-17 16:58                             ` Anton VG
2009-02-17 17:15                               ` Pablo Neira Ayuso [this message]
2009-02-17 17:31                                 ` Anton VG
2009-02-18  2:48                                   ` Amos Jeffries
2009-02-17 17:34                                 ` Anton VG
2009-02-17 19:51                                   ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=499AF0B8.5060202@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=anton.vazir@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=vitaly@eastera.tj \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).