On 07/24/2014 05:53 AM, Patrick McHardy wrote:
On 24. Juli 2014 09:49:27 GMT+01:00, Florian Westphal <fw@xxxxxxxxx> wrote:
Josh Hunt <johunt@xxxxxxxxxx> wrote:
Currently when we do do this the new parameters are not enforced.
Note that:
-A INPUT -m hashlimit --hashlimit-upto 10/sec --hashlimit-burst 10
--hashlimit-name test
-A INPUT -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10
--hashlimit-name test
doesn't work as expected either (rule #2 uses config options of #1).
I think is behaviour is so unexpected that I would consider this a
bug...
True, but it's a bug that has existed forever and I've seen scripts that actually rely on this.
I'm not sure if we can silently change this behaviour.
Can you elaborate on what behavior they're relying on? It'd be helpful
to know in case my approach can't be used we might be able to come up
with an alternative.
In the case I describe with a restore it gives the user what I would
expect to be undesired behavior since they would have explicitly changed
the hash's config, but it's not having any affect. In Florian's case the
user would have a number of rules where they've explicitly made
different hash configurations, but all of the rules with the same hash
name would behave the same as the first. Ignoring all of the configs the
user input.
Thanks
Josh
--
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
