On Sun, Oct 23, 2016 at 01:01:51PM +0800, Liping Zhang wrote:
> Hi Anders,
>
> 2016-10-23 0:08 GMT+08:00 Anders K. Pedersen | Cohaesio <akp@xxxxxxxxxxxx>:
> [...]
> > But ct_expr_update_type is only used during the netlink_delinearize
> > postprocess step, and that causes problems, when it is used in
> > combination with flow statements as described in other mail.
>
> I think this is a bug and should be fixed.
>
> > Would you object to dropping (i.e. kernel will not require it and
> > userspace will not include it) the NFTA_RT_FAMILY attribute for ip and
> > ip6 families, but unconditionally including it for the inet family?
>
> After I read your and Pablo's explanation, now I'm not sure which one
> is better. :)
>
> Maybe from this rt nexthop expression, we can get a relatively
> consistent way to handle the INET family properly, either
> explicitly add a _FAMILY_ attribute, or just like ct original saddr,
> completely handle it properly in the nft utility.
Please, use the layer 3 network context as you said. For the inet family,
we would need to bail out in case no context is available.
We can probably get rid of the _FAMILY attribute by introducing
explicit rt keys, ie.
NFTA_RT_NH_IPV4
NFTA_RT_NH_IPV6
I agree the _FAMILY attribute is getting ugly, specifically we don't
need this attribute with classid, so better if we can avoid it.
Thanks!
--
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
