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 -- 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
