All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Cc: netfilter-devel@vger.kernel.org, pablo@netfilter.org
Subject: Re: [linux PATCH 1/5] netfilter: nft_nat: include a flag attribute
Date: Thu, 26 Jun 2014 14:26:54 +0200	[thread overview]
Message-ID: <20140626122654.GF6328@breakpoint.cc> (raw)
In-Reply-To: <20140626121954.3985.35005.stgit@nfdev.cica.es>

Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com> wrote:
> Both SNAT and DNAT (and the upcoming masquerade) can have additional
> configuration parameters, such as port randomization or NAT addressing
> persistence.
> We can cover these scenarios by simply adding a flag attribute for
> userspace to fill when needed.
> 
> The flags to use are defined in include/uapi/linux/netfilter/nf_nat.h,
>  NF_NAT_RANGE_MAP_IPS
>  NF_NAT_RANGE_PROTO_SPECIFIED
>  NF_NAT_RANGE_PROTO_RANDOM
>  NF_NAT_RANGE_PERSISTENT
>  NF_NAT_RANGE_PROTO_RANDOM_FULLY
>  NF_NAT_RANGE_PROTO_RANDOM_ALL
> 
> The caller must take care of not messing up with the flags, as they are
> added unconditionally to the final resulting nf_nat_range.

I dont think that this is desirable.
When userspace knows about NF_NAT_RANGE_FOO but the kernel does not
userspace should be ablre to detect that kernel is too old.

IOW,
>  static int nft_nat_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
> @@ -149,6 +153,9 @@ static int nft_nat_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
>  	} else
>  		priv->sreg_proto_max = priv->sreg_proto_min;
>  
> +	if (tb[NFTA_NAT_FLAGS])
> +		priv->flags = ntohl(nla_get_be32(tb[NFTA_NAT_FLAGS]));
> +
>  	return 0;
>  }

I think that NFTA_NAT_FLAGS desevers further validation that all
flags/bits are known.

  reply	other threads:[~2014-06-26 12:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26 12:19 [linux PATCH 0/5] NAT updates for nf_tables Arturo Borrero Gonzalez
2014-06-26 12:19 ` [linux PATCH 1/5] netfilter: nft_nat: include a flag attribute Arturo Borrero Gonzalez
2014-06-26 12:26   ` Florian Westphal [this message]
2014-06-26 12:20 ` [linux PATCH 2/5] netfilter: nf_nat_masquerade_ipv4: code factorization Arturo Borrero Gonzalez
2014-06-26 12:20 ` [linux PATCH 3/5] netfilter: nf_nat_masquerade_ipv6: " Arturo Borrero Gonzalez
2014-06-26 12:20 ` [linux PATCH 4/5] netfilter: nft_nat: split code in AF parts Arturo Borrero Gonzalez
2014-06-26 12:20 ` [linux PATCH 5/5] netfilter: nft_nat: add masquerade support Arturo Borrero Gonzalez

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=20140626122654.GF6328@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=arturo.borrero.glez@gmail.com \
    --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.