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
--
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
