From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Laurent Fasnacht <l@libres.ch>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] nft: make raw payloads work
Date: Thu, 29 Jun 2017 18:18:40 +0200 [thread overview]
Message-ID: <20170629161840.GA6789@salvia> (raw)
In-Reply-To: <1498036020-22214-1-git-send-email-l@libres.ch>
Hi Laurent,
On Wed, Jun 21, 2017 at 11:07:00AM +0200, Laurent Fasnacht wrote:
> In nftables, there is a rather (IMO) undocumented feature, raw payloads.
>
> It would be useful both for development and to quickly extend nftables for corner cases.
>
> Unfortunately, it is broken in current master (syntax is not consistent between print and parse,
> and any practical usage doesn't work).
>
> This patch defines a new syntax, and makes it usable in practice:
>
> @<protocol>,<base>,<data type>,<offset>,<length>
>
> Example (rewrite arp packet target hardware address if target protocol address matches a given address):
>
> meta iif enp2s0 arp ptype 0x0800 arp htype 1 arp hlen 6 arp plen 4 @arp,nh,ipv4_addr,192,32 192.168.143.16 @arp,nh,ether_addr,144,48 set 11:22:33:44:55:66 accept;
One thing related to this example: Would you send a patch to extend
the arp family to match sender/target fields in the header? We only
support ARP IPv4, so we can assume the header is "fixed size" for the
offset layout definitions. See src/proto.c, have a look at the arp
protocol definition.
Regarding raw protocol matching. Depending on the datatype, we may not
need the size. I mean, in case of the ipv4_addr datatype, this is
already 4 bytes. For (the generic) integer type fields, we need this
size indeed.
So I think we should allow two different syntax, one with size, and
another with no size. If you select a datatype with a fixed size, then
bail out during the parser/evaluation phase.
Something else: If the user specifies a raw expression that matches a
protocol field that is already defined by nft, this should
automatically translate this to the native nft representation.
It would be also great if you could add a bit of tests for the
tests/py infrastructure, or at least, document the bunch of examples
you have used to test this.
Thanks!
prev parent reply other threads:[~2017-06-29 16:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 9:07 [PATCH] nft: make raw payloads work Laurent Fasnacht
2017-06-29 16:18 ` Pablo Neira Ayuso [this message]
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=20170629161840.GA6789@salvia \
--to=pablo@netfilter.org \
--cc=l@libres.ch \
--cc=netfilter-devel@vger.kernel.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.