Re: 2.5.67 -- questions about netfilter config options

Re: 2.5.67 -- questions about netfilter config options

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 3884 bytes --]

On Tue, Apr 08, 2003 at 07:15:45AM -0400, Robert P. J. Day wrote:
> 
>   [while i'm discussing these things on the netfilter mailing
> list, i figure at least a few folks here might be helpful.]
> 
>   i'm trying to clarify the purpose and interdependence of 
> the NF config options, and perhaps document them more clearly
> in their associated help screens.  to that end, i'm confused
> by the way some options can be selected without other 
> options that would seem to be obvious dependencies.
> to wit:

so why didn't you take this to the netfilter development mailinglist
first?  I don't think this is of general interest to linux-kernel, which
certainly has more than enough postings per day, and the subject is
clearly netfilter-only.

> 1) currently, it's possible to select the single option
>    "IP tables support" without any other options *anywhere*
>    in that menu.  what value does this have?

this means that you have the generic iptables core. this enables you for
example to use some out-of-kernel compiled iptables_foo module. 

compare this with enabling scsi support, but not enabling a single scsi
host.

>    if you look down the submenu for that option, you see
>    "Packet filtering", which suggests you can ask for 
>    "IP tables support" but still not have any ability to
>    set up any filtering rules.  

yes, this makes sense.  packet filtering is the 'filter' table.  It is
perfectly legal to use NAT ('nat' table) or mangling ('mangle') without
enabling packet filtering.

> sort of strange.  it seems
>    odd that you can select to support limit matches,
>    TTL matches, etc., without actually having basic
>    "Packet filtering" support built in.  what does this
>    mean?

see above.

>    one possibility is that, according to the help info,
>    "IP tables support" is necesasry for masq/NAT.  if
>    this is true, it leads into my next question ...

it is true.

> 2) currently, it's possible to select "Connection tracking"
>    without "IP tables support", even though the latter is
>    listed as being essential for masq/NAT as well.
> 
>    what is the value of selecting only "Conenction tracking"
>    in the entire NF config menu?  that is, what does it allow
>    you to do if not masq/NAT?

connection tracking provides a service to the kernel.  If you load it,
any code within the kernel can derive the connection tracking entry to
which a packet belongs.  Even though there is no current code in the
kernel (besides iptable_nat and ipt_state) that uses this information,
we should not decide on that.  

A possible application would be something like a 'cfq' (derived from the
stochastic fairness queue).  This would eliminate the 'stochastic' part
which tries to determine which 'flow' (basically one direction of a
connection) a packet belongs to.

> i guess i'm trying to clarify whether there should be more
> dependencies in the underlying config structure, or it not,

no, at least not from the point of view of the netfilter coreteam.

> rday
> 
> p.s.  is there a reason that almost all of the options
> are listed as "(NEW)" in the config menu?  they weren't
> even labelled that way in the 2.4.20 kernel.  how is it
> that they're suddenly "NEW" now?

Everything marked as 'NEW' means that your .config file did not contain
a setting (i.e. it was copied from a kernel that didn't have support for
those options).  This is also used for 'make oldconfig'.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]