On Fri, 17 Aug 2012, Pablo Neira Ayuso wrote:
> Hi Patrick,>> On Thu, Aug 09, 2012 at 10:08:57PM +0200, kaber@trash.net wrote:>> From: Patrick McHardy <kaber@trash.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 netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html