Re: libnetfilter_queue question

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

В Срд, 04/05/2011 в 20:13 +0200, Alessandro Vesely пишет:
> On 04.05.2011 08:14, nowhere wrote:
> > 5. Worker threads accept packets, which (if I understand correctly)
> > still reside in kernel netfilter queue
> 
> Part of them are copied to user's space (no payload but only metadata,
> according to your use of nfq_set_mode).
> 
> > Then I do the following to test the setup:
> > iptables -t mangle -A POSTROUTING -p icmp -d 10.77.130.72 -j NFQUEUE
> > --queue-num 1
> > 
> > and then start ping. If i do normal ping, everything works like expected
> > 
> > $ping 10.77.130.72
> > PING 10.77.130.72 (10.77.130.72) 56(84) bytes of data.
> > 64 bytes from 10.77.130.72: icmp_req=1 ttl=64 time=97.0 ms
> > 64 bytes from 10.77.130.72: icmp_req=2 ttl=64 time=97.1 ms
> > 64 bytes from 10.77.130.72: icmp_req=3 ttl=64 time=97.6 ms
> > 64 bytes from 10.77.130.72: icmp_req=4 ttl=64 time=93.6 ms
> > 64 bytes from 10.77.130.72: icmp_req=5 ttl=64 time=101 ms
> > 64 bytes from 10.77.130.72: icmp_req=6 ttl=64 time=94.8 ms
> > 
> > Packets are passed to the target host, delay is applied. Stats from
> > application and fro iptables counters show consistent figures.
> > 
> > But when I issue flood ping I see this:
> > $ sudo ping 10.77.130.72 -i0
> > PING 10.77.130.72 (10.77.130.72) 56(84) bytes of data.
> > 64 bytes from 10.77.130.72: icmp_req=1 ttl=64 time=111 ms
> > 64 bytes from 10.77.130.72: icmp_req=8 ttl=64 time=118 ms
> > 64 bytes from 10.77.130.72: icmp_req=9 ttl=64 time=114 ms
> > 64 bytes from 10.77.130.72: icmp_req=10 ttl=64 time=104 ms
> > 64 bytes from 10.77.130.72: icmp_req=11 ttl=64 time=93.5 ms
> > 64 bytes from 10.77.130.72: icmp_req=12 ttl=64 time=93.9 ms
> > 64 bytes from 10.77.130.72: icmp_req=13 ttl=64 time=94.3 ms
> > 64 bytes from 10.77.130.72: icmp_req=14 ttl=64 time=101 ms
> > 64 bytes from 10.77.130.72: icmp_req=15 ttl=64 time=96.8 ms
> > 
> > There are 7 packets dropped at the beginning.
> 
> I assume you meant 6 (15 - 9)

Yes :)

> 
> > Several packets at the beginning get lost.
> 
> Are they always at the beginning, or does that depend on the distribution of
> delays?

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.

> 
> > iptables counters show, that NFQUEUE rule has processed all the packets
> > (15 in this example), app debug output shows 15 processed packets,
> 
> They were seen, but it seems the verdict didn't arrive in time for 6 of them.
> 
> > nfqueue stat show no drops, tc -s -d qdisc show dev eth0 shows no drops
> > in the interface queue. But tcpdump has caught only 9 packets on remote
> > and on local hosts.
> 
> The relationship between filter and local tcpdump is not always obvious, IME.
>  Perhaps, your choice of table/chain makes it better.  Anyway, the remote
> host cannot get it wrong.  Did you dump requests, responses, or both?

Requests only. Do you recommend queuing from another tables/chain?
I tried OUTPUT in filter table, but did not see any difference...

> 
> > There is app's source code here. Maybe, I'm doing something wrong in it?
> 
> I see nothing wrong in it.  However, I'd print out occurrences of rv < 0
> after recv() and look for errno==ENOBUFS in particular.  It should report
> lost packets

Yes, I did it (actually this was one of the first checks). There are no
situations when rv < 0.

> .
> 
> hth
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html