From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] netfilter: xt_hashlimit: restore per-rule effectiveness
Date: Wed, 06 Oct 2010 17:07:49 +0200 [thread overview]
Message-ID: <4CAC90C5.9050206@trash.net> (raw)
In-Reply-To: <alpine.LNX.2.01.1010061625270.27021@obet.zrqbmnf.qr>
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.
prev parent reply other threads:[~2010-10-06 15:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-06 6:28 xt_hashlimit: restore per-rule effectiveness Jan Engelhardt
2010-10-06 6:28 ` [PATCH] netfilter: " Jan Engelhardt
2010-10-06 13:54 ` Patrick McHardy
2010-10-06 15:00 ` Jan Engelhardt
2010-10-06 15:07 ` Patrick McHardy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CAC90C5.9050206@trash.net \
--to=kaber@trash.net \
--cc=jengelh@medozas.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).