From: Alessandro Vesely <vesely@tana.it>
To: nowhere <nowhere@hakkenden.ath.cx>
Cc: netfilter@vger.kernel.org
Subject: NFQUEUE looses packets between arrival and verdict
Date: Wed, 11 May 2011 19:27:49 +0200 [thread overview]
Message-ID: <4DCAC715.3090206@tana.it> (raw)
In-Reply-To: <1304587479.6402.3.camel@compot-mob>
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.
>> 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-11 17:27 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 ` Alessandro Vesely [this message]
2011-05-11 22:56 ` NFQUEUE looses packets between arrival and verdict Ed W
2011-05-12 9:40 ` nowhere
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=4DCAC715.3090206@tana.it \
--to=vesely@tana.it \
--cc=netfilter@vger.kernel.org \
--cc=nowhere@hakkenden.ath.cx \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.