From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [iptables-nftables PATCH 6/6] xtables: add suport for DNAT rule translation to nft extensions
Date: Wed, 15 May 2013 14:51:55 +0200 [thread overview]
Message-ID: <20130515125155.GB1349@localhost> (raw)
In-Reply-To: <51932FBC.1060904@linux.intel.com>
Hi Tomasz,
On Wed, May 15, 2013 at 09:48:28AM +0300, Tomasz Bursztyka wrote:
[...]
> >>+static struct nft_rule_expr_list *
> >>+create_nat_expr_list(const struct nf_nat_range *r)
> >>+{
> >>+ struct nft_rule_expr_list *expr_list;
> >>+ struct nft_rule_expr *nat_expr;
> >>+ int registers = 1;
> >>+
> >>+ expr_list = nft_rule_expr_list_alloc();
> >>+ if (expr_list == NULL)
> >>+ return NULL;
> >Better allocate this list in nft.c and pass it as parameter. All
> >extensions will require this, and after that change you can return -1
> >on error / 0 on success.
> >
> >Or simply pass the struct nft_rule object? Then, you can skip patch
> >[libnftables PATCH 6/7]?
>
> Why not, it's a design preference. I liked the idea extension don't
> mess up with the rule and only provides its expression list.
> it's less code on libnftables on your idea at least.
We have to trust our iptables extensions.
What extra sanity checking are you going to make anyway if the
extension puzzles with this internal expr_list?
> >>+ .x6_options = DNAT_opts,
> >>+ .translate_to_nft = DNAT_to_nft,
> >nft_to_translate is missing, right? We need it to print the rule that
> >is expressed in native format.
>
> Read the very first mail of this thread. It's actually an issue here.
> I had the idea of doing the reverse function indeed, but there is a problem:
> From iptables to nftables it's easy, since we get a target made by
> the right extension, so we directly get the right translation
> function. That's what I did.
>
> Now on the reverse way, we don't know at all to which extension the
> expression list belongs to, so which translation function to call.
> Currently the only way I see it is to loop on all extensions until
> one returns successfully.
You need some dispatcher code that interprets the nft_expr and routes
it to the right iptables extension. So you will need also one .c file
per expression in the kernel, e.g. nft_nat.c, that performs this
dispatching / routing to the right extension.
Probably checking netlink_delinearize.c in nft can provide your some
ideas.
> We should take care of the position in the expression list as well,
> and here I see we will need some more functions from libnftables.
You have the expression iterator already.
next prev parent reply other threads:[~2013-05-15 12:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 10:49 [iptables-nftables/libnfables PATCHES] Target translation to nftables Tomasz Bursztyka
2013-05-14 10:51 ` [libnftables PATCH 0/7] Fixes and features Tomasz Bursztyka
2013-05-14 10:51 ` [libnftables PATCH 1/7] git: add a .gitignore file Tomasz Bursztyka
2013-05-14 22:17 ` Pablo Neira Ayuso
2013-05-15 6:51 ` Tomasz Bursztyka
2013-05-15 12:53 ` Pablo Neira Ayuso
2013-05-15 13:01 ` Tomasz Bursztyka
2013-05-14 10:51 ` [libnftables PATCH 2/7] build: add an autogen.sh script Tomasz Bursztyka
2013-05-14 10:51 ` [libnftables PATCH 3/7] rule: declare nft_rule_list structure at a proper place Tomasz Bursztyka
2013-05-14 10:51 ` [libnftables PATCH 4/7] expr: remove inconsistent and non implemented function Tomasz Bursztyka
2013-05-14 10:51 ` [libnftables PATCH 5/7] map: fix nft_rule_expr_build_payload export Tomasz Bursztyka
2013-05-14 10:51 ` [libnftables PATCH 6/7] expr: add support for expr list and capability to add it into a rule Tomasz Bursztyka
2013-05-14 10:51 ` [libnftables PATCH 7/7] chain: handle attribute is relevant if only there is no name to use Tomasz Bursztyka
2013-05-14 22:20 ` Pablo Neira Ayuso
2013-05-15 6:08 ` Tomasz Bursztyka
2013-05-15 12:43 ` Pablo Neira Ayuso
2013-05-15 13:06 ` Tomasz Bursztyka
2013-05-15 13:40 ` Pablo Neira Ayuso
2013-05-15 13:54 ` Tomasz Bursztyka
2013-05-15 14:28 ` Pablo Neira Ayuso
2013-05-16 16:46 ` [libnftables PATCH 0/7] Fixes and features Pablo Neira Ayuso
2013-05-14 10:52 ` [iptables-nftables PATCH 0/6] " Tomasz Bursztyka
2013-05-14 10:52 ` [iptables-nftables PATCH 1/6] xtables: initialize xtables defaults even on listing rules Tomasz Bursztyka
2013-05-16 17:01 ` Pablo Neira Ayuso
2013-05-14 10:52 ` [iptables-nftables PATCH 2/6] xtables: destroy list iterator relevantly Tomasz Bursztyka
2013-05-16 17:02 ` Pablo Neira Ayuso
2013-05-14 10:52 ` [iptables-nftables PATCH 3/6] xtables: policy can be changed only on builtin chain Tomasz Bursztyka
2013-05-16 17:01 ` Pablo Neira Ayuso
2013-05-14 10:52 ` [iptables-nftables PATCH 4/6] xtables: Add support for translating xtables target into nft expressions Tomasz Bursztyka
2013-05-14 10:52 ` [iptables-nftables PATCH 5/6] xtables: add support for translating xtables matches " Tomasz Bursztyka
2013-05-14 10:52 ` [iptables-nftables PATCH 6/6] xtables: add suport for DNAT rule translation to nft extensions Tomasz Bursztyka
2013-05-14 22:30 ` Pablo Neira Ayuso
2013-05-15 6:48 ` Tomasz Bursztyka
2013-05-15 12:51 ` Pablo Neira Ayuso [this message]
2013-05-15 13:24 ` Tomasz Bursztyka
2013-05-15 13:49 ` Pablo Neira Ayuso
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=20130515125155.GB1349@localhost \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=tomasz.bursztyka@linux.intel.com \
/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).