Re: xt_statistic.c - the statistic match

[Bryan Duff <bduff@astrocorp.com>]

Jan Engelhardt wrote:
> On Thursday 2009-01-15 16:46, Bryan Duff wrote:
>   
>>> 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.
>>     
>
> It depends on the module and the implementation. As for -A/-I/-Z, all
> private data will usually be retained. Only when the actual rule that
> references a module is deleted, the private data of the module _may_
> be removed too -- this obviously does not apply for modules that have
> an information storage that can be referenced multiple times, such as
> xt_recent, xt_condition or xt_quota2.
>
> So if you want to have the nth state be zeroed too, it's best to use
> iptables-restore to insert them all at once into the kernel.
>
>   
>> 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.
>>     
>
> Oopses, where?
>   
I'm sorry - it doesn't kernel panic.  But the count will get out of sync 
continually (well after the rule has been put in place).  This problem 
has nothing to do with adding the rule.   Because it works just fine ... 
for a while.  Sending packets for an hour can cause this problem to 
happen a good half-dozen times at least.  So I say oopses in the sense 
that the module does not work as intended.

Once again the problem deals with the internal counter: 
"info->u.nth.count++".  If the problem was adding the rule it would only 
happen once.

-Bryan