bugzilla-daemon at netfilter.org
2013-May-31 16:25 UTC
[Bug 650] --hashlimit-burst does not update when using --hashlimit-name for a second time
https://bugzilla.netfilter.org/show_bug.cgi?id=650 Phil Oester <netfilter at linuxace.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED CC| |netfilter at linuxace.com Resolution| |INVALID --- Comment #7 from Phil Oester <netfilter at linuxace.com> 2013-05-31 18:25:34 CEST --- Andre: you claim to be "editing" the hashlimit rule, but your images clearly show you are using iptables -A, not -R. So you are simply adding to the end of the chain, not editing the existing rule at all. As such, you should not expect different behaviour given the first rule you added will continue to match. Jan: this is simply how hashlimit works. Unless the count of rules using a given hash goes to zero, the hash will NOT be cleared of all its entries. And this makes sense, in cases where someone might be using the same hash in multiple rules. Changing one rule should not clear the hash contents. If you want this behavior, instead of using -R you will need to use -D then -A (or -I). Assuming you only have one rule using the hash, the -D will destroy the hash and the -A/-I will recreate it. Closing this bug. Hashlimit appears to be working as designed. -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
Maybe Matching Threads
- [Bug 650] --hashlimit-burst does not update when using --hashlimit-name for a second time
- [Bug 568] New: iptables-save saves option hashlimit-htable-gcinterval with error
- [Bug 1740] New: hashlimit limit: reduction to lowest terms in the output is confusing
- [Bug 1320] New: iptables hashlimit - problem with traffic limitation
- [Bug 1273] New: hashlimit never appears to fail to match under 4.9.x