From: Patrick McHardy <kaber@trash.net>
To: Amin Azez <azez@ufomechanic.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: xtables Re: Hacking iptables 1.3.5 for 2.6.17
Date: Fri, 30 Jun 2006 18:08:05 +0200 [thread overview]
Message-ID: <44A54C65.20906@trash.net> (raw)
In-Reply-To: <44A5496C.3030504@ufomechanic.net>
Amin Azez wrote:
> Patrick McHardy wrote:
>
>>Amin Azez wrote:
>>
>>>I notice a lot of things have moved to net/netfilter/xt_*.c
>>>
>>>Is this an absolute requirement, or is there some compatability system?
>>
>>No requirement, things can just stay where they are.
>>
>>
>>>I'm porting the layer7 match first, currently when adding a layer7 rule
>>>I get (dmesg):
>>>[71987.513531] ip_tables: layer7 match: invalid size 0 != 8452
>>
>>8452? Thats ridiculous much
>
>
> too right! Layer7 permits up to 8192 for the regex - like anyone is
> going to want to run a regex that long on every packet (well the first
> few of each connection)
>
> Whats anyones feelings on flexible sizes of iptables match structs?
Its not possible with the current architecture, and overcoming this
would probably not be worth it measured in both time and the resulting
uglyness compared to just introducing a netlink interface.
> Right now layer7 does a linear search through a cache of pre-compiled
> regexes with the original regex as the key - PER PACKET - it would make
> much more sense to store a pointer to the cached regex in the matchinfo
> - which is what I'm doing now; but the lack of extra kernelside fields
> is restrictive, so I'm canibalizing (in an ugly way) the last few bytes
> of the refex field.
Thats a bit of a different problem. Per-instance private data will soon
be possible in a nicer way.
>>.. anyway, you need to initialize the
>>.matchsize field to sizeof(struct ...) (the one shared with userspace).
>
>
> aye, that works fine, thanks.
> To my surprise I'm getting checkinfo called lots of times, I thought it
> would only be called once when a new rule was being accepted
> kernel-side. Do you know why it would be called many times (with the
> same value matchinfo pointer)
It gets called whenever you add a new rule. Thats a result of the
atomic-exchange of the entire ruleset, each "generation" of your
ruleset (while adding rules incrementally) is an entirely new
ruleset to the kernel.
next prev parent reply other threads:[~2006-06-30 16:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-30 9:10 Hacking iptables 1.3.5 for 2.6.17 Amin Azez
2006-06-30 9:48 ` Yasuyuki KOZAKAI
[not found] ` <200606300948.k5U9mNot001866@toshiba.co.jp>
[not found] ` <44A50091.7070003@ufomechanic.net>
2006-06-30 11:57 ` Yasuyuki KOZAKAI
2006-06-30 12:40 ` xtables " Amin Azez
2006-06-30 12:51 ` Sam Liddicott
2006-06-30 14:39 ` Patrick McHardy
2006-06-30 15:55 ` Amin Azez
2006-06-30 16:08 ` Patrick McHardy [this message]
2006-06-30 16:28 ` Amin Azez
2006-06-30 16:37 ` Patrick McHardy
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=44A54C65.20906@trash.net \
--to=kaber@trash.net \
--cc=azez@ufomechanic.net \
--cc=netfilter-devel@lists.netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.