Ð ÐÑÐ, 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
