Mr. Nordstrom,
--- Henrik Nordstrom <[EMAIL PROTECTED]> wrote:
> On Saturday 29 June 2002 11.46, Patrick McHardy wrote:
>
> > A CONNMARK patch will follow but currently CONNMARK doesn't apply
> > clean against 2.4.18/2.4.19-pre10 ..
>
> Note: There is two versions of the CONNMARK patch. The one in extra
> applies if you are using the new_nat patch, the one on old_nat if
> not.
>
> Your last posting did stir up some discussion on how to deal with
> this. Adding a "terminate" option to each and every of these
> psuedo-targets is clearly not the way to go, and only cover a very
> small subset of what is needed.
>
> I proposed adding a new class of iptables things between matches and
> targets, being neither a match for filtering or a target that
> determines the ultimate fate of the packet. The names proposed for
> these in the discussion was modifiers or actions.
I think modifier is a better term. "Action" sounds more like "target"
and may confuse new users of iptables.
>
> The implementation of these can be done without needing to change the
> kernel iptables API by simply piggying back on the match list in the
> table structure. The modifiers/actions need to register themselves as
> a match, and for compability with old rulesets and/or userspace tools
> as a target as well..
>
> The userspace tools need to have a new option for calling a
> modifier/action. These should clearly be separated from matches.
Has the option letter been decided on yet?
>
> So the question to the Netfilter core team is if it would be OK to add
> a new option and "module class" to the userspace tools, and have the
> existing IPT_CONTINUE targets dual-register as both a target and a
> match. I can try to whip something together if this is seen as
> something acceptable. Should be fully backwards/forward compatible
> with existing rulesets with only a minimal amount of code
> duplication. The only compability issue is that if you make use the
> new feature then you cannot go back to a older userspace or kernel.
I would like to see a feature like this because it makes the iptables
syntax cleaner and easier to understand. The only difficulty I see is backward
compatibility with older kernels and older iptables installations. You mentioned
using a piggyback mechanism for the ipt_match/ipt_target structs to prevent
API changes. Will a new API eventually emerge (ipt_modifier)? And if a new API
does emerge, what kernel version would it be aimed for (2.4.xx? 2.5.xx?)
Also, BTW: will this facility appear in iptables2 as well?
>
> Regards
> Henrik
>
Brad
=====
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
