[Tfug] ip_tables kernel code no longer possible to build into the kernel?

[Robert Hunter]

> make oldconfig is not letting me build iptables support (code that
> runs as part of the kernel, sometimes called a module) into the
> kernel.
> make oldconfig is not letting me build iptables support (code that
> runs as part of the kernel, sometimes called a module) into the
> kernel.

It's possible that in your kernel configuration a dependency for
IP_NF_IPTABLES is configured as a module, which would explain why you
only have the option of building this feature as a module.  Let's do
some grepping in the Linux source tree to see what it depends on.

<shell interaction>
$grep -r IP_NF_IPTABLES net
net/ipv4/netfilter/Kconfig:config IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:       depends on IP_NF_IPTABLES && XFRM
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES && IP_NF_CONNTRACK
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES!=n &&
IP_NF_CONNTRACK!=n && IP_NF_NAT!=n
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES!=n &&
IP_NF_CONNTRACK!=n && IP_NF_NAT!=n
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES!=n &&
IP_NF_CONNTRACK!=n && IP_NF_NAT!=n
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES!=n &&
IP_NF_CONNTRACK!=n && IP_NF_NAT!=n
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Kconfig:     depends on IP_NF_IPTABLES
net/ipv4/netfilter/Makefile:obj-$(CONFIG_IP_NF_IPTABLES) += ip_tables.o
net/sched/Kconfig:        depends on NET_CLS_ACT && NETFILTER &&
IP_NF_IPTABLES
</shell interaction>

The first line is the only one that is not a dependency on
IP_NF_IPTABLES.  Let's look at it  closer.

<shell interaction>
$grep -C 10 'config IP_NF_IPTABLES'  net/ipv4/netfilter/Kconfig
       help
         Netfilter has the ability to queue packets to user space: the
         netlink device can be used to access them using this driver.

         This option enables the old IPv4-only "ip_queue" implementation
         which has been obsoleted by the new "nfnetlink_queue" code (see
         CONFIG_NETFILTER_NETLINK_QUEUE).

         To compile it as a module, choose M here.  If unsure, say N.

config IP_NF_IPTABLES
       tristate "IP tables support (required for filtering/masq/NAT)"
       depends on NETFILTER_XTABLES
       help
         iptables is a general, extensible packet identification framework.
         The packet filtering and full NAT (masquerading, port forwarding,
         etc) subsystems now use this: say `Y' or `M' here if you want to use
         either of those.

         To compile it as a module, choose M here.  If unsure, say N.
</shell interaction>

>From this we can see that it depends on NETFILTER_XTABLES.  Now we can
go check the config to see if NETFILTER_XTABLES is configured
statically or as a module.  If we have the same problem ( i.e. only
has a module option ) then we could repeat the process.  You could
probably write a script to help with this if you really wanted to.

As to why you need this kernel feature compiled statically, I can only
guess.  If you were trying to despense with initrd ( i.e. you are
dealing with something that is required during the boot process ),
then it makes sense to compile it directly into the kernel.  In this
case, I would guess that a kernel module would work equally well.



-- 
Rob