Re: NFQUEUE the plot is growing...

["Nikolay S." <nowhere@hakkenden.ath.cx>]

В Чтв, 12/05/2011 в 20:03 +0200, Alessandro Vesely пишет:
> On 12/May/11 11:40, nowhere wrote:
> >> 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.
> 
> I retract, possibly I've been too hasty blaming nfnetlink queue.  I
> made a simple variation of nfqnl_test.c --which I attach.  It just
> accepts the previous packet id.  The "last" packet is obviously always
> lost.  Because of this bug(?), I also loose the second packet of a
> sequence of pings, no matter the speed.
> 
> However, if I "ping -c 1" using two terminal windows, I correctly
> receive all odd ids in one window and even ones in the other (except
> last pkt).  In this case, I delay every packet.  Also, if I run a
> sequence from a window, and, immediately after it starts, run a single
> ping using the other window, then both the single ping and the
> sequence (except last pkt) go correctly through.
> 
> I don't understand how come the kernel+filter system can distinguish
> between a second packet coming as part of a sequence and a second
> packet coming asynchronously, given that packets are not inspected.
> Nice puzzle, isn't it?
> 
> 
> NB, I used iptables -t mangle -A POSTROUTING -p icmp -d 172.25.197.158
> -j NFQUEUE --queue-num 13, as in
> http://www.spinics.net/lists/netfilter/msg50829.html


Hi there,

There is a case that look similar to ours:
http://marc.info/?l=netfilter-devel&m=129016166319433&w=2

So I tried putting iptables rule in raw table (afaik it is passed before
conntrack, so delayed packets are not being tracked before entering
queue) - and the problem is solved, there are no drops anymore.