Hi Phil,
I'm recovering this RFC that got lost in the pile.
On Wed, May 10, 2017 at 05:34:29PM +0200, Phil Sutter wrote:
> Hi,
>
> Netfilter Bugzilla #949[1] complains about broken output when trying to
> match icmpv6 message fields. This is a problem in how payload match is
> implemented in nft: The given match (e.g. 'icmp6 id 2') is broken down
> to a simple match of header data at a specific offset. Sadly this does
> not work with ICMP(v6) since header structure depends on the packet's
> ICMP type and on return path there is no information about which type of
> message the user wanted to match against.
Right, this is a longstanding bug.
> My idea was to build something like the protocol dependencies we have
> for e.g. TCP header fields but with ICMP, a given header field might be
> present in multiple message types (e.g. icmp6_id is present in echo
> request as well as reply).
You mean adding more instructions when generating bytecode? This has
runtime overhead, just to provide context for just listing the
ruleset. I would prefer we skip this.
> I already considered inserting a match for icmp6 type against an
> anonymous set (like 'icmp6 type { echo-request, echo-reply }'), but
> having this as an implicit dependency and resolving with previous
> matches, etc. becomes pretty complex.
>
> Do you think I should try following a different approach (via userdata
> e.g.)?
I think you should try adding some context structure to the
expr_print(), this context can be used to interpret this offset based
on the icmp type.
Someone (Elise?) send me a patch to add this context structure, just
to prepare introduction, but she got stuck in the context update
logic at some point. I can find such patch so you only have to figure
out how to annotate the information we need in this context structure.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
