From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bryan Duff Subject: Re: xt_statistic.c - the statistic match Date: Thu, 15 Jan 2009 09:46:36 -0600 Message-ID: <496F5A5C.1070504@astrocorp.com> References: <4967CDCB.3080306@astrocorp.com> <496B7F66.40900@astrocorp.com> <38bcb3ec0901150237nc2d8316l62c27beef7e59170@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James King , netfilter-devel@vger.kernel.org To: Jan Engelhardt Return-path: Received: from mail.astrocorp.com ([75.160.64.129]:21656 "EHLO mail.astrocorp.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1753045AbZAOPpO (ORCPT ); Thu, 15 Jan 2009 10:45:14 -0500 In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: Jan Engelhardt wrote: > On Thursday 2009-01-15 11:37, James King wrote: > >>>>> //snip - iptables -L >>>>> 978189 1210792980 ACCEPT all -- ethX * 10.10.10.0/24 >>>>> 10.10.11.0/24 MARK match 0x1 >>>>> 2182885 2704995300 ACCEPT all -- ethX * 10.10.10.0/24 >>>>> 10.10.11.0/24 MARK match 0x2 >>>>> 2289382 2862482240 ACCEPT all -- ethX * 10.10.10.0/24 >>>>> 10.10.11.0/24 MARK match 0x3 >>>>> 1417708 1807169776 MARK all -- ethX * 10.10.10.0/24 >>>>> 10.10.11.0/24 MARK set 0x1 >>>>> 1417708 1807169776 ACCEPT all -- ethX * 10.10.10.0/24 >>>>> 10.10.11.0/24 MARK match 0x1 >>>>> >>> //end snip >>> >> I'm a bit curious about this. I thought it was only possible to use >> the MARK target in mangle, but you seem to be listing the filter >> table. I notice that mark_tg_reg[] revision 2 doesn't limit the table >> to mangle like r0 and r1 do (anyone know if this a bug, or is r2 >> intended to be available everywhere?) >> > > Just posted moments ago: > http://marc.info/?l=netfilter-devel&m=123200677329507&w=2 > > >> If you're using iptables to commit these rules individually (as your >> first message implies) and the system is under traffic already, it's >> easy for them to get out of sync because each nth rule tracks its own >> state individually and MARK is non-terminating. >> > > And iptables -Z should take care of the counters if rules are added > one-by-one. Also noteworthy is that when iptables is run, the > ruleset (including counters) is downloaded from the kernel, and > later uploaded again - possible setting counters backwards. > (I do no think there are any workarounds to that in the kernel, > at least I have not seen any.) > But at least all of the counters are set to where they were. > Would iptables -Z fix the internal counter for the statistic nth match rule? I don't see that it would. Because that's the counter I really care about fixing. A couple things - this problem occurs multiple times after adding the rules (as in it can correct itself by oops'ing again), the other amusing thing - if I use printk's I can make it happen faster, also if I'm doing more throughput it happens faster. -Bryan