Netfilter Kconfig: Expose IPv4/6 connection tracking options by selecting NF_CONNTRACK_E

Make NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6 select
NF_CONNTRACK_ENABLED.

This exposes IPv4/6 connection tracking options for easier
Kconfig setup.

Signed-off-by: Al Boldi <a1426zgawab.com>
Cc: Patrick McHardy <kabertrash.net>
Cc: David Miller <davemdavemloft.net>
Cc: Sam Ravnborg <samravnborg.org>
Cc: Andrew Morton <akpmlinux-foundation.org>
---
--- a/net/netfilter/Kconfig	2007-07-09 06:38:52.000000000
+0300
+++ b/net/netfilter/Kconfig	2007-07-25 17:37:16.000000000
+0300
 -28,6
+28,7  config NETFILTER_NETLINK_LOG
 # Rename this to NF_CONNTRACK in a 2.6.25
 config NF_CONNTRACK_ENABLED
 	tristate "Netfilter connection tracking
support"
+	select NF_CONNTRACK
 	help
 	  Connection tracking keeps a record of what packets have
passed
 	  through your machine, in order to figure out how they
are related
--- a/net/ipv4/netfilter/Kconfig	2007-07-09
06:38:50.000000000 +0300
+++ b/net/ipv4/netfilter/Kconfig	2007-07-25
17:37:39.000000000 +0300
 -7,7
+7,7  menu "IP: Netfilter Configuration"
 
 config NF_CONNTRACK_IPV4
 	tristate "IPv4 connection tracking support (required
for NAT)"
-	depends on NF_CONNTRACK
+	select NF_CONNTRACK_ENABLED
 	---help---
 	  Connection tracking keeps a record of what packets have
passed
 	  through your machine, in order to figure out how they
are related
--- a/net/ipv6/netfilter/Kconfig	2007-07-09
06:38:51.000000000 +0300
+++ b/net/ipv6/netfilter/Kconfig	2007-07-25
17:37:57.000000000 +0300
 -7,7
+7,8  menu "IPv6: Netfilter Configuration (EXP
 
 config NF_CONNTRACK_IPV6
 	tristate "IPv6 connection tracking support
(EXPERIMENTAL)"
-	depends on INET && IPV6 && EXPERIMENTAL
&& NF_CONNTRACK
+	depends on INET && IPV6 && EXPERIMENTAL
+	select NF_CONNTRACK_ENABLED
 	---help---
 	  Connection tracking keeps a record of what packets have
passed
 	  through your machine, in order to figure out how they
are related

[Removed a few CCs]

Al Boldi wrote:
> Make NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6 select
NF_CONNTRACK_ENABLED.


One thought that occured to me after the last of many false
bugreports
that were actually caused by failure to configure the new
options
properly. Most people know they want NF_CONNTRACK (and its
selected by
default with old configs), what they're missing is that they
now also
need to select IPv4 connection tracking. So what would
really make sense
is to make NF_CONNTRACK_IPV4 default to "m" (and
really *everyone*
using conntrack wants this). But with your proposed change
this would
default to selecting NF_CONNTRACK by default, which I'm not
so sure
is a good idea. So I'm leaning towards just using
"m" as default for
IPv4 conntrack to save people trouble and myself some
bugreports, but
I also like your simplification ...

Maybe we can do something to have the NF_CONNTRACK_ENABLED
option select
NF_CONNTRACK_IPV4 (which really is what we actually want)
and combine
that with automatic selection of NF_CONNTRACK? I believe the
only case
with negative impact would be people that currently use only
IPv6
connection tracking, which is most likely nobody.

From: Patrick McHardy <kabertrash.net>
Date: Thu, 26 Jul 2007 02:46:05 +0200

> [Removed a few CCs]
> 
> Al Boldi wrote:
> > Make NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6
select NF_CONNTRACK_ENABLED.
> 
> 
> One thought that occured to me after the last of many
false bugreports
> that were actually caused by failure to configure the
new options
> properly. Most people know they want NF_CONNTRACK (and
its selected by
> default with old configs), what they're missing is that
they now also
> need to select IPv4 connection tracking. So what would
really make sense
> is to make NF_CONNTRACK_IPV4 default to "m"
(and really *everyone*
> using conntrack wants this). But with your proposed
change this would
> default to selecting NF_CONNTRACK by default, which I'm
not so sure
> is a good idea. So I'm leaning towards just using
"m" as default for
> IPv4 conntrack to save people trouble and myself some
bugreports, but
> I also like your simplification ...
> 
> Maybe we can do something to have the
NF_CONNTRACK_ENABLED option select
> NF_CONNTRACK_IPV4 (which really is what we actually
want) and combine
> that with automatic selection of NF_CONNTRACK? I
believe the only case
> with negative impact would be people that currently use
only IPv6
> connection tracking, which is most likely nobody.

I agree. I've not heard trouble with NF_CONNTRACK_IPV6. I
think that is
because it is purely new feature.

BTW, it's too late to restore IP_NF_CONNTRACK in stable and
current tree
for a while ?

-- Yasuyuki Kozakai

Patrick McHardy wrote:
> Al Boldi wrote:
> > Make NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6
select
> > NF_CONNTRACK_ENABLED.
>
> One thought that occured to me after the last of many
false bugreports
> that were actually caused by failure to configure the
new options
> properly. Most people know they want NF_CONNTRACK (and
its selected by
> default with old configs), what they're missing is that
they now also
> need to select IPv4 connection tracking. So what would
really make sense
> is to make NF_CONNTRACK_IPV4 default to "m"
(and really *everyone*
> using conntrack wants this). But with your proposed
change this would
> default to selecting NF_CONNTRACK by default, which I'm
not so sure
> is a good idea.

Making NF_CONNTRACK_IPV4 default to "m" would
select NF_CONNTRACK to "m" if 
it hasn't been selected by the user to be "y",
which seems reasonable.

> So I'm leaning towards just using "m" as
default for
> IPv4 conntrack to save people trouble and myself some
bugreports, but
> I also like your simplification ...

I was also planning to submit another patch to make all
netfilter 
childoptions options default to their parent, i.e:
NF_CONNTRACK_FTP would 
default NF_CONNTRACK.  This could be one big Kconfig
time-saver.

> Maybe we can do something to have the
NF_CONNTRACK_ENABLED option select
> NF_CONNTRACK_IPV4 (which really is what we actually
want) and combine
> that with automatic selection of NF_CONNTRACK? I
believe the only case
> with negative impact would be people that currently use
only IPv6
> connection tracking, which is most likely nobody.

I think that wouldn't be advisable, as this would add an
unnecessary 
dependency.  But of course,  it's your call...


Thanks!

--
Al