Re: xt_statistic.c - the statistic match

[Bryan Duff <bduff@astrocorp.com>]

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