Re: [PATCH nft 04/10] tests: fix up meta l4proto change for ip6 family

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, May 17, 2017 at 08:36:53PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > What would you expect in these cases (note, ip family):
> > > 
> > > a) add rule filter input meta l4proto icmpv6
> > > b) add rule filter input meta l4proto icmpv6 icmpv6 type echo-request
> > > c) add rule filter input icmpv6 type echo-request
> > >
> > > with master only a) is accepted.
> > > With patch #1 of the series, b) is also accepted.
> > 
> > b) and c) are equivalent. Since c) should generate both the meta
> > protocol and the meta l4proto dependency.
> 
> Hmm.  I suspect you mean c) should be rejected?
> (ip family!), so user would have to specify

Oh, I thought these examples above are inet.

Yes, we should reject this from ip family.

> > Then, we should allow this too:
> > 
> >         meta protocol ip meta l4proto icmpv6
> 
> Explicitly to indicate ip->protocol == 58 is asked for.

Exactly.

> > so we can match IPv4 packets that container ICMPv6 packet. I know,
> > this is crazy, but we should users to match this. A handcrafted packet
> > may look like that.
> 
> Yes and yeas.
> 
> > I think this logic should be placed somewhere at payload_gen_dependency().
> 
> Ok, I will rework this series accordingly, i.e.:
> 
> add rule filter input icmpv6 type echo-request

This above should be ip6 family, right?

> will:
> - pull in meta l4proto dependency for ip6 family
> - pull in meta l4proto dependency PLUS ipv6 dependency in
> inet/bridge/netdev families
> - fail with invalid protocol base error in ip family
>
> the last case should work in ip family iff user specifies
> the nexthdr value specifically.
> 
> Does that seem ok to you?

Sounds great, thanks.