schuster.sven at gmx.de
Wed Jul 20 17:01:18 CEST 2005
On Wed, Jul 20, 2005 at 04:15:44PM +0200, Michael Schachtebeck told us:
> As I could not test the rules that Jan has suggested in his answer to my
> postings (it's a production machine and I couldn't reboot it with a
> patched kernel so far), I did some more testing and discovered a very
> strange behaviour which I believe to be indeed a bug:
... <testing snipped>
> So this seems to be a bug in the kernel's iptables implementation, right?
I think this is "expected behaviour" and it behaves like that
because of the implentation of netfilter.
AFAIK, when you add, delete, replace a iptables rule, at first the
current rules are "downloaded" from kernel, the changes are made in
user space, then the ruleset is "uploaded" again to the kernel.
When uploading, I think that all the internal data structures for the
matches are deleted and then allocated freshly. That's why you see
this behaviour in your testing. When your cronjob runs (or you run
it manually) all the data structures get deleted and newly allocated,
thus the limit rule matches again.
Of course, anybody feel free to correct me if I'm wrong :-)
> I'm using a 18.104.22.168 vanilla kernel and iptables 1.2.11 (gentoo package
Linux zion 2.6.13-rc3-mm1 #6 PREEMPT Mon Jul 18 19:42:52 CEST 2005 i686 athlon i386 GNU/Linux
16:59:48 up 1 day, 21:12, 1 user, load average: 0.49, 0.21, 0.07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter/attachments/20050720/d0b235c5/attachment.bin
More information about the netfilter