Thanks for the quick reply. The system I'm dealing often has traffic spikes that cause NFQ packet drops. So I can't put a counter in userspace because it would miss dropped packets. Counting dropped packets (as a percentage of the total number of packets) is the main reason why I'm trying to get the correct number of packets sent to the NFQ in the first place... On Sun, May 26, 2013 at 1:42 PM, Florian Westphal <fw@xxxxxxxxx> wrote: > Alex Maltinsky <maltalex@xxxxxxxxx> wrote: >> I've stumbled across the issue on a heavily loaded system that uses >> the nfqueue. After a few days, the number of packets wraps around: >> >> root@xxxx ~ # cat /proc/net/netfilter/nfnetlink_queue >> 1 2401 1024 2 4096 247495836 0 -894731272 1 > > -8.... is not the number of packets, its the nfqueue sequence number, > which is a 32bit value (admittingly, it should use %u instead of %d > to avoid the '-' silliness). > >> Is this a new issue or has it been fixed in recent versions? > > No, it has been like this forever. > >> I couldn't find anything in the changelog so I've decided not to >> update libnfnetlink since it's an otherwise stable production machine >> running a three year old version (0.0.39). > > Has nothing todo with libnfnetlink, the procfs contents are > from netfilter_queue kernel part. > >> Second, is there a way of getting the correct value besides keeping >> track of the number of wraparounds and compensating for them? > > If you want to know the number of packets processed by application > you should simply add uint64_t counter in userspace and increment > it per-packet. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
