sfrost at snowman.net
Thu Dec 30 15:18:57 CET 2004
* Samuel (sj-netfilter at cookinglinux.org) wrote:
> Here's the testcase for the ipt_recent module.
Hey, that's kinda neat (that you can write a testcase like that :).
> Note that it really doesn't behave like I think it should.
I'm guessing you're referring to the 'FIXME'/'BUG' things below?
> # Test #4: Using --hitcount in solo limiting 5 packets & more.
> # We expect to NF_DROP 5th and 6th packet. IMO
> # FIXME: Actually it only drops 6th packet. Shouldn't this
> # acts the same on 5th packet ?
> echo iptables -I INPUT -m recent --name testcase --rsource \
> --hitcount 5 --rcheck -j DROP
> echo iptables -A INPUT -m recent --name testcase --set --rsource -j ACCEPT
> for pkt in 1 2 3 4 5; do # The 4 packets we send + an unexpected 5th
> echo expect gen_ip hook:NF_IP_LOCAL_IN iptable_filter NF_ACCEPT '*'
> echo gen_ip IF=eth0 192.168.0.2 192.168.0.1 0 17 1 2
Well, you're using --rcheck and --set, and the --set is coming *after*
the --rcheck. --rcheck doesn't change anything, so when packet #5 comes
through the '--set' has been done *4* times. It isn't until packet #5
passes --set that the hitcount for that packet becomes 5. It's an
interesting thing to think about as to if --update should behave the
same way or not. At the moment it does because the
--update/modification logic is after the --update/check logic. That
wouldn't be too hard to change, but then that'd end up producing
different results than the --rcheck/--set above, which I'm not sure I
Hope that helps. Were there any other issues? Looked like everything
else was correct, but I might have missed something.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/netfilter-devel/attachments/20041230/2a0330c6/attachment.bin
More information about the netfilter-devel