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