Ð ÐÑÐ, 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. -- 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
