From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton VG 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 22:31:41 +0500 Message-ID: References: <4996FBBE.20009@netfilter.org> <200902161819.27630.anton.vazir@gmail.com> <49996D49.9050606@netfilter.org> <49998504.9020004@netfilter.org> <499AF0B8.5060202@netfilter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netfilter-devel , Vitaly Bodzhgua To: Pablo Neira Ayuso Return-path: Received: from fk-out-0910.google.com ([209.85.128.187]:7756 "EHLO fk-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752793AbZBQRbo (ORCPT ); Tue, 17 Feb 2009 12:31:44 -0500 Received: by fk-out-0910.google.com with SMTP id f33so1411622fkf.5 for ; Tue, 17 Feb 2009 09:31:42 -0800 (PST) In-Reply-To: <499AF0B8.5060202@netfilter.org> Sender: netfilter-devel-owner@vger.kernel.org List-ID: Pablo, Thanks so much for patch, will test it shortly, Do you have any suggestion what method to use if not select() ? Since we have to handle potentially thousands of queues on the single PC? Sincerely, Anton. 2009/2/17 Pablo Neira Ayuso : > 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 > > 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) > >