On Fri, Oct 21, 2016 at 09:22:09PM +0800, Liping Zhang wrote:
> Hi Pablo,
>
> 2016-10-21 17:21 GMT+08:00 Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>:
> [...]
> >> In init ctx->afi->family is available, a example code is in nft_ct_get_init(),
> >> you can take a look at this.
> >
> > ctx->afi->family indicates NFPROTO_INET in this case, so we have no
> > way to know if the user is requesting rt IPv4 or rt IPv6 from there.
>
> Yes, but I find that the NFTA_RT_FAMILY attr seems only useful
> in init routine. For INET family, the length can simply to be setted
> to sizeof(struct in6_addr), i.e:
> switch (ctx->afi->family) {
> case IPV4:
> len = 4;
> break;
> case IPV6:
> case INET:
> len = 16;
> break;
> }
> ...
> return nft_validate_register_store(..., len, ...);
>
> The drawback of this implementation is that the user cannot
> specify dreg to NFT_REG32_13, NFT_REG32_14 and
> NFT_REG32_15 when we use rt4 nexthop in INET family.
>
> But since the same problem exists when we use rt6 nexthop in
> INET/IPV6 family, so I think this will not be a problem.
>
> And for eval, nft rules can be interpreted as following:
> (1) nft add rule filter inet output rt ip nexthop ... --debug=netlink
> [ meta load nfproto => reg 1 ]
> [ cmp eq reg 1 0x00000002 ]
> [ rt nexthop => reg 1 ]
> ...
>
> (2) nft add rule filter inet output rt ip6 nexthop ... --debug=netlink
> [ meta load nfproto => reg 1 ]
> [ cmp eq reg 1 0x0000000a ]
> [ rt nexthop => reg 1 ]
> ...
>
> So I think we cannot earn much benefits from the NFTA_RT_FAMILY attr.
> Or I missed something?
We still need datatype information for the inet family, from the
netlink_delinearize step, when dumping back the policy to userspace.
Given that we cannot infer the datatype from the data size, as this
would be 16 bytes for both cases, we would still need to annotate this
context information somewhere. The existing approach is providing this
datatype information.
--
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
