All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: BORBELY Zoltan <bozo@andrews.hu>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	Netfilter Development Mailinglist
	<netfilter-devel@vger.kernel.org>
Subject: Re: Support NAT-ed expect entries from user space
Date: Mon, 23 Jun 2008 17:56:16 +0200	[thread overview]
Message-ID: <485FC7A0.6080506@trash.net> (raw)
In-Reply-To: <20080623153153.GE3261@phoenix.home>

BORBELY Zoltan wrote:
> On Tue, Jun 17, 2008 at 12:43:37AM +0200, Patrick McHardy wrote:
>   
>> I understand that, the expectation part looks like a subset of what
>> a helper module does though, with the only differences that a helper
>> might want to queue the packet. And since expectfn setup also doesn't
>> belong in nf_conntrack_netlink.c (especially not NAT related expectfns),
>> this is how I think it should be done.
>>     
>
> I attached a new version of the expect setup patch. I think it's general
> enough to include into the kernel. What's your opinion? The saved_ip
> field is only used by the nf_nat_sip and nf_nat_h323 helpers, we only
> need it if we want to set expectfn of our choice.
>
>   
> +++ linux/net/netfilter/nf_conntrack_netlink.c	2008-06-23 17:00:26.000000000 +0200
> +#ifdef CONFIG_NF_NAT_NEEDED
> +	if (cda[CTA_EXPECT_NAT]) {
> +		exp->expectfn = nf_nat_follow_master;
> +		err = nla_parse_nested(tb, CTA_EXPNAT_MAX,
> +				       cda[CTA_EXPECT_NAT], NULL);
> +		if (err < 0)
> +			goto out;
> +
> +		if (tb[CTA_EXPNAT_SAVED_PROTO])
> +			exp->saved_proto.all = nla_get_be16(tb[CTA_EXPNAT_SAVED_PROTO]);
> +		if (tb[CTA_EXPNAT_DIRECTION]) {
> +			exp->dir = nla_get_u8(tb[CTA_EXPNAT_DIRECTION]);
> +			if (exp->dir != IP_CT_DIR_ORIGINAL &&
> +			    exp->dir != IP_CT_DIR_REPLY) {
> +				err = -EINVAL;
> +				goto out;
> +			}
> +		} else
> +			exp->dir = IP_CT_DIR_ORIGINAL;
> +	}
> +#endif
>   

As I said previously, NAT related things don't belong in
nf_conntrack_netlink.c. The existing ones should be moved
out since they add module dependencies that are simply wrong
(conntrack should *never* depend on NAT).

This patch also adds an interface that is too specialized
for your use case instead of doing it in a way that is
generically useful, which would mean at least providing
helper private expectfn selection. The expectfn selection
should probably use the expectation classes, although I'm
open to be convinced otherwise.



  reply	other threads:[~2008-06-23 16:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080616092148.GB2860@phoenix.home>
2008-06-16 20:10 ` Support NAT-ed expect entries from user space Pablo Neira Ayuso
2008-06-16 20:52   ` Patrick McHardy
2008-06-16 22:17     ` BORBELY Zoltan
2008-06-16 22:43       ` Patrick McHardy
2008-06-17 15:05         ` Patrick McHardy
2008-06-23 15:31         ` BORBELY Zoltan
2008-06-23 15:56           ` Patrick McHardy [this message]
2008-06-16 21:29   ` BORBELY Zoltan

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=485FC7A0.6080506@trash.net \
    --to=kaber@trash.net \
    --cc=bozo@andrews.hu \
    --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 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.