On 06.10.2010 17:00, Jan Engelhardt wrote:
> On Wednesday 2010-10-06 15:54, Patrick McHardy wrote:
>
>> Am 06.10.2010 08:28, schrieb Jan Engelhardt:
>>> When adding a second hashlimit rule with the same name, its parameters
>>> had no effect, because it had used a copy of the first one's inner
>>> state.
>>
>> I'm not sure we can change this behaviour at this point. There's at
>> least one change in your patch that changes the default behaviour,
>> you can currently create a second rule for a table witout specifying
>> the mode
>
> I don't think that works. iptables does not know how many hashlimit
> rules there are, thus it always enforces the presence of
> --hashlimit-name, --hashlimit-mode and so on.
No, revision 1 only checks for limit and name.
>>> @@ -452,34 +456,34 @@ hashlimit_init_dst(const struct xt_hashlimit_htable *hinfo,
>>>
>>> memset(dst, 0, sizeof(*dst));
>>>
>>> - switch (hinfo->family) {
>>> + switch (family) {
>>
>> This also looks problematic, the entries don't include the family
>> themselves, so you're allowing tables to contain entries of multiple
>> families, which might cause mismatches.
>
> AFAICS, one can already mix v4 and v6 into the same hashlimit bucket
> at this time (including side effects).
No, currently the tables include the family as key. Actually your
patch doesn't allow that either, but it doesn't make sense to change
hashlimit_init_dst to use par->family instead of hinfo->family.
--
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
