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

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 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?

Actually i meant

add rule $family filter input icmpv6 type echo-request

... to have the example below illustrate the difference
in behaviour and dependency injection.

> > 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.

Good, I will work on this tomorrow then.

I won't push any of the patches for the time being, so expect a v2.