From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Jan Engelhardt <jengelh@medozas.de>, netfilter-devel@vger.kernel.org
Subject: Re: The glorious NFCT "none" helper
Date: Tue, 07 Jun 2011 12:23:50 +0200 [thread overview]
Message-ID: <4DEDFC36.6070301@trash.net> (raw)
In-Reply-To: <4DDC00FF.6040405@netfilter.org>
On 24.05.2011 21:03, Pablo Neira Ayuso wrote:
> On 24/05/11 09:06, Patrick McHardy wrote:
>> On 23.05.2011 18:13, Pablo Neira Ayuso wrote:
>>> On 23/05/11 17:59, Jan Engelhardt wrote:
>>>> On Monday 2011-05-23 17:47, Pablo Neira Ayuso wrote:
>>>>> On 23/05/11 16:29, Patrick McHardy wrote:
>>>>>> Wouldn't a flag to the CT target to skip the helper lookup work as well?
>>>>>
>>>>> Indeed.
>>>>
>>>> Yes, but how would xt_CT.ko convey to NFCT then that no helper is
>>>> supposed to be used? Calling nf_ct_helper_ext_add, but then leave help
>>>> at NULL?
>>>
>>> You can attach a template conntrack in the raw table with the CT target.
>>> That template should have some status flag set to skip helper
>>> allocation/assignation.
>>
>> Problem might be the second lookup done after NAT. We don't have the
>> template available at that time.
>
> We'll have some IPS_NO_HELPER flag set for the conntrack at that time to
> skip the helper assignation.
>
>> I don't like the dummy helper idea very much though, what I would
>> prefer is an option to use only explicit helper assignment. That
>> would be a more flexible option, additionally allowing to track
>> protocols on any port without specifying each of them when loading
>> the helper.
>
> I don't want to assign a dummy helper, but use a flag to skip helper
> assignation, would you be OK with that idea?
Sure, that sounds like something that would fit into the CT target.
My idea other idea is to have a global option to disable helper
lookups and *only* use explicit assignment, so you can specificy
specifically for which addresses and ports to use helpers.
> BTW, not related with this patch but I'd like to fix the current issue
> with the userspace expectation support problem, still don't like my
> patches to add a template and set one flag to explicitly tell conntrack
> to allocate the helper CT extension?
This is too much exposure of implementation in my opinion, userspace
shouldn't have to care about extension areas. I'll have another look
at your patches to see if I can come up with an alternative.
next prev parent reply other threads:[~2011-06-07 10:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-18 22:21 The glorious NFCT "none" helper Jan Engelhardt
2011-05-18 22:21 ` [PATCH] netfilter: the "none" conntrack helper module Jan Engelhardt
2011-05-23 14:29 ` The glorious NFCT "none" helper Patrick McHardy
2011-05-23 15:47 ` Pablo Neira Ayuso
2011-05-23 15:59 ` Jan Engelhardt
2011-05-23 16:13 ` Pablo Neira Ayuso
2011-05-24 7:06 ` Patrick McHardy
2011-05-24 19:03 ` Pablo Neira Ayuso
2011-06-07 10:23 ` Patrick McHardy [this message]
2011-06-07 11:09 ` 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=4DEDFC36.6070301@trash.net \
--to=kaber@trash.net \
--cc=jengelh@medozas.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@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 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).