netdev - Re: [PATCH 13/19] netfilter: ip6tables: add MASQUERADE target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 18 Aug 2012 14:31:01 +0200 (MEST)
From:	Patrick McHardy <kaber@...sh.net>
To:	Pablo Neira Ayuso <pablo@...filter.org>
cc:	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 13/19] netfilter: ip6tables: add MASQUERADE target

On Fri, 17 Aug 2012, Pablo Neira Ayuso wrote:

> Hi Patrick,
>
> On Thu, Aug 09, 2012 at 10:08:57PM +0200, kaber@...sh.net wrote:
>> From: Patrick McHardy <kaber@...sh.net>
>>
> Please, add this chunk to this patch:
>
> diff --git a/include/net/netfilter/nf_nat.h
> b/include/net/netfilter/nf_nat.h
> index 1752f133..bd8eea7 100644
> --- a/include/net/netfilter/nf_nat.h
> +++ b/include/net/netfilter/nf_nat.h
> @@ -43,7 +43,9 @@ struct nf_conn_nat {
>        struct nf_conn *ct;
>        union nf_conntrack_nat_help help;
> #if defined(CONFIG_IP_NF_TARGET_MASQUERADE) || \
> -    defined(CONFIG_IP_NF_TARGET_MASQUERADE_MODULE)
> +    defined(CONFIG_IP_NF_TARGET_MASQUERADE_MODULE) || \
> +    defined(CONFIG_IP6_NF_TARGET_MASQUERADE) || \
> +    defined(CONFIG_IP6_NF_TARGET_MASQUERADE_MODULE)
>        int masq_index;
> #endif
> };
>
> Otherwise, compilation breaks with:
>
> * IPv4 NAT is disabled
> * IPv6 NAT enabled.

Fixed, thanks.

>
> And yes, that pile of ifdefs is really ugly, I wonder if they are
> worth for saving 4 bytes. I think most vendors usually include
> MASQUERADE support if NAT is enabled.
>
> It seems we have the tradition of keeping several similar compile time
> options in Netfilter to optimize memory in several situations (at the
> cost of polluting the code with ifdefs). Probably we can think of
> getting rid of them.

Well, vendors maybe, but what about embedded systems? I have some which
are *really* short on memory. They limit conntrack to very few entries
though, so it doesn't make that much of a difference.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html