Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

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

On Fri, Oct 21, 2016 at 02:17:11PM +0800, Liping Zhang wrote:
> hi Anders,
> 
> 2016-10-21 12:16 GMT+08:00 Anders K. Pedersen | Cohaesio <akp@cohaesio.com>:
> >>
> >> But after I think it carefully, I think the NFTA_RT_FAMILY attr
> >> seems useless, we can combine these four files nft_rt.c,
> >> nft_rt_ipv4.c, nft_rt_ipv6.c and nft_rt_inet.c into a single one
> >> file nft_rt.c.
> >
> > My implementation is based on the suggestion from Pablo at
> > http://marc.info/?l=netfilter-devel&m=147438531502686&w=4 .
> 
> Yes, but after I carefully read your codes, I find that the related
> implementation code about the family attr is not very good.
> 
> Without the family attr, we can still make everything well, and
> the codes will become more clean and straightforward.
> 
> As a summary:
> For ip family, nexthop must be ipv4
> For ip6 family, nexthop must be ipv6
> For inet family, nexthop can be selected by pkt->pf and we can add
> an implict rule that the user cannot do wrong operation.
> 
> So I think the NFTA_RT_FAMILY attr is almost useless.
>
> >> For eval, we can use pkt->pf to decide which rt or rt6 nexthop
> >> to be loaded, so ip/ip6/inet family has the same logical now,
> >> for example:
> >
> > Yes, but pkt->pf is not available in init, where we have to answer what
> > the data size will be.
> 
> 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.