Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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 > Then, we should allow this too: > > meta protocol ip meta l4proto icmpv6 Explicitly to indicate ip->protocol == 58 is asked for. > 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 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? Thanks, Florian -- 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
