From: nowhere <nowhere@hakkenden.ath.cx>
To: Alessandro Vesely <vesely@tana.it>
Cc: netfilter@vger.kernel.org
Subject: Re: NFQUEUE looses packets between arrival and verdict
Date: Thu, 12 May 2011 13:40:07 +0400 [thread overview]
Message-ID: <1305193207.9902.8.camel@compot-mob> (raw)
In-Reply-To: <4DCAC715.3090206@tana.it>
В Срд, 11/05/2011 в 19:27 +0200, Alessandro Vesely пишет:
> Finally I've found some time to try that. Sorry for the delay.
>
> On 05/May/11 11:24, nowhere wrote:
> >>> Indeed. The first packet is never dropped, then comes a serie of drops
> >>> (the number of dropped packets depends on the sending rate, i.e. testing
> >>> with iperf on, say, 50 Mbit/s shows drops of ~800 packets) and after
> >>> that no drops at all. Distribution and it's parameters do not matter
> >>> except for zeroes: if there is no artificial delay, no packets are
> >>> dropped.
>
> It seems enough to avoid delaying the call to nfq_set_verdict for the
> first packet of a burst. For a shot in the dark, packets seem to get
> lost if they arrive between the first one and the corresponding call
> to nfq_set_verdict. Indeed, setting a fixed real_delay of 0.2, with
> ping -i 0.2 it looses no packets, with ping -i 0.19 it looses just the
> second one, with ping -i 0.09 icmp_reqs #2 and #3.
>
> No error is returned, whether NETLINK_NO_ENOBUFS is set or not.
Well, seems like this is the case. If nfqueue becomes empty, first
enqueued packet must not be delayed. Adding queue length check and skip
delaying first packet eliminates drops.
But... delay may be due to packet processing, and hence unavoidable. I
mean, this "workaround" is not a workaround...
> >> Did you check return codes from nfq_set_verdict()? If that is 0, it must be
> >> a bug. I meant >= 0 here ----------------^
> >
> > nfq_set_verdict() returns 32
>
> AFAIK the library does not queue data, so I'd guess the bug is in the
> kernel. I hope someone else chimes in and explains some more of this.
> (I change the subject trying to draw attention.)
>
> > I'm using Gentoo x86_64 v2.6.38-gentoo-r4 (2.6.38.5 + minor patches).
> > libnetfilter_queue is 0.0.17
>
> Same on Debian x86_64 2.6.32-something, and libnetfilter_queue 0.0.17
next prev parent reply other threads:[~2011-05-12 9:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 6:14 libnetfilter_queue question nowhere
2011-05-04 18:13 ` Alessandro Vesely
2011-05-04 18:32 ` Nikolay S.
2011-05-05 9:12 ` Alessandro Vesely
2011-05-05 9:24 ` nowhere
2011-05-11 17:27 ` NFQUEUE looses packets between arrival and verdict Alessandro Vesely
2011-05-11 22:56 ` Ed W
2011-05-12 9:40 ` nowhere [this message]
2011-05-12 18:03 ` NFQUEUE the plot is growing Alessandro Vesely
2011-05-13 18:25 ` Nikolay S.
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=1305193207.9902.8.camel@compot-mob \
--to=nowhere@hakkenden.ath.cx \
--cc=netfilter@vger.kernel.org \
--cc=vesely@tana.it \
/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).