On Wed, Jul 17, 2019 at 07:17:43PM +0200, Phil Sutter wrote:
> Trying to create an inet family nat chain would not cause
> nft_chain_nat.ko module auto-load due to missing module alias.
>
> The family is actually NFPROTO_INET which happens to be the same
> numerical value as AF_UNIX.
>
> Signed-off-by: Phil Sutter <p...@nwl.cc>
> ---
> This is obviously a hack to illustrate the problem and show a working
> solution. I'm not sure what a real fix would look like - maybe nf_tables
> should internally use NFPROTO_* defines instead of AF_* ones? Maybe it
> should translate NFPROTO_INET into AF_UNSPEC?
> ---
> net/netfilter/nft_chain_nat.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/netfilter/nft_chain_nat.c b/net/netfilter/nft_chain_nat.c
> index 2f89bde3c61cb..d3bf4a297c655 100644
> --- a/net/netfilter/nft_chain_nat.c
> +++ b/net/netfilter/nft_chain_nat.c
> @@ -142,3 +142,6 @@ MODULE_ALIAS_NFT_CHAIN(AF_INET, "nat");
> #ifdef CONFIG_NF_TABLES_IPV6
> MODULE_ALIAS_NFT_CHAIN(AF_INET6, "nat");
> #endif
> +#ifdef CONFIG_NF_TABLES_INET
> +MODULE_ALIAS_NFT_CHAIN(AF_UNIX, "nat");
Please, use (2, "nat") instead like in other extensions.
MODULE_ALIAS_NFT_CHAIN(2, "nat"); /* NFPROTO_INET */
Yes, it's not nice, but this is so far what we have.
I agree we should fix this, problem is that NFPROTO_* are enum, and
IIRC this doesn't mix well with the existing macros.
If you want to have a look, that would be great.
Thanks.
