more questions about kernel config options for iptables

more questions about kernel config options for iptables

[Robert P. J. Day]

  having poked around even more in the options, i must say
i'm a little puzzled.  mostly, i'm interested in understanding
what some of these options do all by themselves, so forgive me
if i end up repeating myself.

  first, the basic Connection tracking option claims to be
necessary for masq/NAT.  what value is that option if it is
the only one selected?  it may be *necesasry* for masq/NAT,
but it certainly doesn't seem to be *sufficient*.  what is
the value of selecting that single option to the exclusion
of all others.  what does it allow you to do?

  next, notice that "IP tables support" also claims to be
necessary for masq/NAT.  if that's the case, it would seem
that these two options should somehow be interdependent.

  another way of looking at it might be, why would anyone
select "Connection tracking in the first place"?  might it
not be more reasonable to have the user select the 
*functionality* they want, and have something like
that basic connection tracking option as an invislble
dependency?

  to that end, it would make more sense to have a restructured
menu with more obvious options like

  Basic filtering
  Simple NAT
  Masquerading

and so on.  the actual object files associated with these
*functions* are of no interest to the user.  he/she cares
only about what can be done afterwards.

  here's another question.  notice the options under 
"Connection tracking".  first, i'm aware that because of 
the way FTP works, you need some connection tracking ability
to filter it properly.  so this is just straight FTP
filtering.

  note, however, that the next three options -- IRC,
TFTP and Amanda -- refer to using those protocols
in conjunction with NAT or masquerading.  if this is
the case, i can see having FTP in one submenu associated
with filtering, with the others in a submenu associated
with NAT/masq.  it just seems to make more sense that way.

  anyway, comments?

rday

Re: more questions about kernel config options for iptables

[Joel Newkirk]

On Monday 07 April 2003 05:18 pm, Robert P. J. Day wrote:
>   having poked around even more in the options, i must say
> i'm a little puzzled.  mostly, i'm interested in understanding
> what some of these options do all by themselves, so forgive me
> if i end up repeating myself.
>
>   first, the basic Connection tracking option claims to be
> necessary for masq/NAT.  what value is that option if it is
> the only one selected?  it may be *necesasry* for masq/NAT,
> but it certainly doesn't seem to be *sufficient*.  what is
> the value of selecting that single option to the exclusion
> of all others.  what does it allow you to do?

Conntrack is what supports stateful filtering - without it you won't have 
the "--state" match, and can only filter explicitly on IPs, port 
numbers, etc.

>   next, notice that "IP tables support" also claims to be
> necessary for masq/NAT.  if that's the case, it would seem
> that these two options should somehow be interdependent.

Well, if you're going to use MASQUERADE then you need iptables support, 
even if you're not going to use iptables for any filtering.

>   another way of looking at it might be, why would anyone
> select "Connection tracking in the first place"?  might it
> not be more reasonable to have the user select the
> *functionality* they want, and have something like
> that basic connection tracking option as an invislble
> dependency?

For some users, perhaps, but Linux has grown up in (or has gathered, 
depends on your perspective) a community of people who want to know what 
is going on, and have fine-grain control over it at will.  Perhaps some 
day there will be a "make easyconfig" option that will set whole banks 
of appropriate settings based on high-level spoon-fed questions 
targeting a completely non-technical user.  But ATM I'm not aware of any 
'real' kernel config working this way, as kernel building is still 
targetted largely at the knowledgeable linux-savvy user/admin.

>   to that end, it would make more sense to have a restructured
> menu with more obvious options like
>
>   Basic filtering
>   Simple NAT
>   Masquerading
>
> and so on.  the actual object files associated with these
> *functions* are of no interest to the user.  he/she cares
> only about what can be done afterwards.
>
>   here's another question.  notice the options under
> "Connection tracking".  first, i'm aware that because of
> the way FTP works, you need some connection tracking ability
> to filter it properly.  so this is just straight FTP
> filtering.

Actually you can filter it (presuming you mean 'allow it to pass') 
without conntrack, but your resulting firewall is not nearly as tight as 
it would otherwise be...

>   note, however, that the next three options -- IRC,
> TFTP and Amanda -- refer to using those protocols
> in conjunction with NAT or masquerading.  if this is
> the case, i can see having FTP in one submenu associated
> with filtering, with the others in a submenu associated
> with NAT/masq.  it just seems to make more sense that way.

Actually all four (and others) are conntrack and nat helpers that are 
needed both for stateful filtering AND nat, AFAIK.

>   anyway, comments?

Not to be a smartass, but if you're unsatisfied with the options or their 
groupings, you can always contribute to the kernel effort... :^) 
{kernelsourcetreeroot}/net/ipv4/netfilter/Config.in  is the file that 
controls the construction of the netfilter/iptables-related options 
during make xconfig/menuconfig etc.

> rday

j

Re: more questions about kernel config options for iptables

[Joel Newkirk]

On Tuesday 08 April 2003 03:04 am, Joel Newkirk wrote:
>
> For some users, perhaps, but Linux has grown up in (or has gathered,
> depends on your perspective) a community of people who want to know
> what is going on, and have fine-grain control over it at will. 
> Perhaps some day there will be a "make easyconfig" option that will
> set whole banks of appropriate settings based on high-level spoon-fed
> questions targeting a completely non-technical user.  But ATM I'm not
> aware of any 'real' kernel config working this way, as kernel building
> is still targetted largely at the knowledgeable linux-savvy
> user/admin.

> Not to be a smartass, but if you're unsatisfied with the options or
> their groupings, you can always contribute to the kernel effort... :^)
> {kernelsourcetreeroot}/net/ipv4/netfilter/Config.in  is the file that
> controls the construction of the netfilter/iptables-related options
> during make xconfig/menuconfig etc.

Doh!  Just read your previous post.  Please disregard my stupidity... ;^)

j

Re: more questions about kernel config options for iptables

[Robert P. J. Day]

On Tue, 8 Apr 2003, Joel Newkirk wrote:

> On Monday 07 April 2003 05:18 pm, Robert P. J. Day wrote:

> >   first, the basic Connection tracking option claims to be
> > necessary for masq/NAT.  what value is that option if it is
> > the only one selected?  it may be *necesasry* for masq/NAT,
> > but it certainly doesn't seem to be *sufficient*.  what is
> > the value of selecting that single option to the exclusion
> > of all others.  what does it allow you to do?
> 
> Conntrack is what supports stateful filtering - without it you won't have 
> the "--state" match, and can only filter explicitly on IPs, port 
> numbers, etc.

not quite the question i was asking.  read on ...

> >   next, notice that "IP tables support" also claims to be
> > necessary for masq/NAT.  if that's the case, it would seem
> > that these two options should somehow be interdependent.
> 
> Well, if you're going to use MASQUERADE then you need iptables support, 
> even if you're not going to use iptables for any filtering.

right, that's what the kernel config options seem to suggest.
so what is the value of selecting *only* "Connection tracking"
if you don't select "IP tables support" as well?  note that,
based on the dependencies in the kernel config process, this is
certainly allowable, but it's not clear to me what this would
represent.

RECAP:  just to make sure folks understand what i'm trying to 
clarify, here are two "features" of the kernel config process
for netfilter i find confusing:

1) you can select "IP tables support" without selecting one
   of its submenu options, "Packet filtering".  what is the
   possible value of this?  what can you do?  as i read it,
   perhaps it means that you can still do filter-less
   NAT and masquerading.  if that's the case, i can accept
   that.

2) you can select "Connection tracking" (which is allegedly
   required for NAT/masq), without selecting "IP tables support",
   which also claims to be necessary for NAT/masq.  this
   suggests that "Connection tracking" should have a dependency
   of "IP tables support", no?

i have three tentative goals here:

a) to clarify what each of the NF kernel config options
   represents

b) to make sure all of the dependencies are represented

c) to clean up the menu structure so that it makes more
   sense, and possibly add more useful info to the help
   screens

i'm quite willing to move this discussion to the kernel
mailing list if it's more appropriate there, but i figured
i'd start here first.

rday

Re: more questions about kernel config options for iptables

[Arnt Karlsen]

On Tue, 8 Apr 2003 03:44:24 -0400, 
Joel Newkirk <netfilter@newkirk.us> wrote in message 
<200304080344.24650.netfilter@newkirk.us>:

> On Tuesday 08 April 2003 03:04 am, Joel Newkirk wrote:
> 
> > Perhaps some day there will be a "make easyconfig" option that will
> 
> Doh!  Just read your previous post.  Please disregard my stupidity...
> ;^)

..to rub in more salt; check out the make options in the latest 
2.5.6x.  ;-)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: more questions about kernel config options for iptables

[Cedric Blancher]

Le mar 08/04/2003 à 13:01, Robert P. J. Day a écrit :
> > >   first, the basic Connection tracking option claims to be
> > > necessary for masq/NAT.  what value is that option if it is
> > > the only one selected?  it may be *necesasry* for masq/NAT,
> > > but it certainly doesn't seem to be *sufficient*.  what is
> > > the value of selecting that single option to the exclusion
> > > of all others.  what does it allow you to do?

It allows kernel to assemble packets into sessions, which is called
connection tracking, with optional module support for "strange"
protocoles such as FTP or H323, which provides what can be called "level
5" filtering.

With this option only, your kernel will only follow sessions. But as it
does not make decisions wether to accept, refuse or anything else for a
packet based on this, you won't see any visible effect of this.

> right, that's what the kernel config options seem to suggest.
> so what is the value of selecting *only* "Connection tracking"
> if you don't select "IP tables support" as well?  note that,
> based on the dependencies in the kernel config process, this is
> certainly allowable, but it's not clear to me what this would
> represent.

If you don't select IP tables support, then you won't have nat table,
and so won't be able to configure nat stuff. It's the same for mangle
and filter.

> 1) you can select "IP tables support" without selecting one
>    of its submenu options, "Packet filtering".  what is the
>    possible value of this?  what can you do?  as i read it,
>    perhaps it means that you can still do filter-less
>    NAT and masquerading.  if that's the case, i can accept
>    that.

You can select this, and nothing else. This means your kernel is reading
to have tables for IPv4. But he won't have any. It is about the same
than saygin "I want my kernel to support modules", but having no module
at all. You can support them, but you don't use them. You can also
select matches, but not "Packet filtering", "Full NAT" or "Packet
mangling". This will means that you'll have material to create rules
(matches and targets), but no table to place them in (except if you have
your own table).

You have tables support for IPv6 and ARP as well, because you can have a
set of tables for each layer 3 protocol Netfilter handles.

> 2) you can select "Connection tracking" (which is allegedly
>    required for NAT/masq), without selecting "IP tables support",
>    which also claims to be necessary for NAT/masq.  this
>    suggests that "Connection tracking" should have a dependency
>    of "IP tables support", no?

Nope.
Connection tracking does not depend on IP tables, neither IP tables
depends on connection tracking. But, some feature of IP tables depends
on connection tracking, such as state matching and NAT stuff. As you can
see in kernel configuration, if you don't select connection tracking,
you can't select NAT or state matching anymore.

So, I'll try to tell it shortly (the way I understood what you needed).

1. Connection tracking is the ability for the kernel to "assemble"
   packets into connections at layer 3, 4 and 5 using modules (FTP,
   H323, etc.). This does not need user interaction, and so does not
   depend on IP tables support.

2. IP tables support provides tables for IPv4. Tables are attached to
   Netfilter's hook and are the places where users act on what Netfilter
   have to do with packets. So, if you do not have IP tables support,
   you can't act on IPv4 packets, for filtering, nating and mangling.
   IP tables support does not depend on connection tracking. you can
   have tables without connection tracking. But nat table requires
   connection tracking. State matching depends on connection tracking
   too. If you have IP tables support, but no tables available, then you
   can't act on packets too unless you have your own table to attach.

So...
You can have connection tracking without IP tables support. But what is
the point ? I can't see one.
You can have IP tables support without connection tracking, but some
depending options won't be available anymore : NAT and state matching
won't be available.
You can have IP tables support without anything else depending on it.
That will provide your kernel the ability to attach tables, but you
won't have any to attach. What's the point ? Maybe developping your own
table ?

Hope I could make myself clear and have undestood well what you wanted.
It is a quite tricky subject, and I don't know if I can express all I
want into english ;)

> i'm quite willing to move this discussion to the kernel
> mailing list if it's more appropriate there, but i figured
> i'd start here first.

Maybe netfilter-devel list would be a more appropriate place to discuss
this, as I do think Netfilter's core developpers can be far more aware
of such things as many users like me can be.


-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: more questions about kernel config options for iptables

[Robert P. J. Day]

On 8 Apr 2003, Cedric Blancher wrote:

> Le mar 08/04/2003 à 13:01, Robert P. J. Day a écrit :
> > > >   first, the basic Connection tracking option claims to be
> > > > necessary for masq/NAT.  what value is that option if it is
> > > > the only one selected?  it may be *necesasry* for masq/NAT,
> > > > but it certainly doesn't seem to be *sufficient*.  what is
> > > > the value of selecting that single option to the exclusion
> > > > of all others.  what does it allow you to do?
> 
> It allows kernel to assemble packets into sessions, which is called
> connection tracking, with optional module support for "strange"
> protocoles such as FTP or H323, which provides what can be called "level
> 5" filtering.
> 
> With this option only, your kernel will only follow sessions. But as it
> does not make decisions wether to accept, refuse or anything else for a
> packet based on this, you won't see any visible effect of this.

that makes sense.  so selecting "Connection tracking" simply
builds in the *capability* to do connection tracking (implemented,
IIRC, by /proc/net/ip_conntrack), which *can* be used by adding
other options.  by itself, it doesn't seem to support any
user-available "iptables" features, but just having it running
may enable someone to at least view the current connection
tracking status, while not really being able to do anything about
it.
 
> If you don't select IP tables support, then you won't have nat table,
> and so won't be able to configure nat stuff. It's the same for mangle
> and filter.

that's what i thought.  without "IP tables support", there's really
nothing you can do in the way of either filtering or NATting.
although you can still do connection tracking, for all the good
that does you.
 
> > 1) you can select "IP tables support" without selecting one
> >    of its submenu options, "Packet filtering".  what is the
> >    possible value of this?  what can you do?  as i read it,
> >    perhaps it means that you can still do filter-less
> >    NAT and masquerading.  if that's the case, i can accept
> >    that.
> 
> You can select this, and nothing else. This means your kernel is reading
> to have tables for IPv4. But he won't have any. It is about the same
> than saygin "I want my kernel to support modules", but having no module
> at all. You can support them, but you don't use them. You can also
> select matches, but not "Packet filtering", "Full NAT" or "Packet
> mangling". This will means that you'll have material to create rules
> (matches and targets), but no table to place them in (except if you have
> your own table).

in other words, you're building in a *support system* for unselected
features, but without actually picking these features, it's not
doing you much good.  that's why i was thinking that a reworking
of that entire config menu might be in order -- why let users
pick what turns out to be a non-functional set of options?
it would make far more sense to have a list of menu options
that reflects what a user would want to *do*, and have the
underlying dependencies kept invisible.  a more readable menu
like:

   Basic filtering
     Connection tracking
   NAT
   Packet mangling

and so on.  stuff that reflects how someone would *use* iptables,
and now the way it's structured inside the kernel, which most
people don't care about.
 
> You have tables support for IPv6 and ARP as well, because you can have a
> set of tables for each layer 3 protocol Netfilter handles.
> 
> > 2) you can select "Connection tracking" (which is allegedly
> >    required for NAT/masq), without selecting "IP tables support",
> >    which also claims to be necessary for NAT/masq.  this
> >    suggests that "Connection tracking" should have a dependency
> >    of "IP tables support", no?
> 
> Nope.
> Connection tracking does not depend on IP tables, neither IP tables
> depends on connection tracking. But, some feature of IP tables depends
> on connection tracking, such as state matching and NAT stuff. As you can
> see in kernel configuration, if you don't select connection tracking,
> you can't select NAT or state matching anymore.

gotcha.  if you want masq/NAT, you would have to select
not only Connection tracking, but IPtables support and,
within that, "Full NAT".  and that's why i dislike the current
menu layout.  it would be more reasonable for someone to say,
"i want NAT", and have the underlying dependencies automatically
satisfied.

i'll give this some thought, and perhaps move this to 
netfilter-devel, as i was unaware that there was such a
list.

thanks.

rday

Re: more questions about kernel config options for iptables

[Cedric Blancher]

Le mar 08/04/2003 à 14:23, Robert P. J. Day a écrit :
> in other words, you're building in a *support system* for unselected
> features, but without actually picking these features, it's not
> doing you much good.  that's why i was thinking that a reworking
> of that entire config menu might be in order -- why let users
> pick what turns out to be a non-functional set of options?

It is not really non-functional. If I were a developper, I could build a
kernel with IP tables selected and no table, just to test the table I am
developping. That's just an example, but I think someone can find some
good reason ;)
I must admit that, from a strict user poijnt of vue, I can't see any
good reason.

> it would make far more sense to have a list of menu options
> that reflects what a user would want to *do*, and have the
> underlying dependencies kept invisible.  a more readable menu
> like:
> 
>    Basic filtering
>      Connection tracking
>    NAT
>    Packet mangling

This does not reflect reality. Connection tracking does not depend on
basic filtering. It's even completly independent form it. It does not
depend on NAT either.

> gotcha.  if you want masq/NAT, you would have to select
> not only Connection tracking, but IPtables support and,
> within that, "Full NAT".  and that's why i dislike the current
> menu layout.  it would be more reasonable for someone to say,
> "i want NAT", and have the underlying dependencies automatically
> satisfied.

I see your point. But I do think connection tracking has to appear as a
independent choice. But some conntrack dependencies could appear
non-selected. As an example, NAT could appear anyway, and if you were to
select it, then it would automaticly select connection tracking as well.
I don't know if it's possible to do such dependencies into kernel
configuration (in fact, I don't think so).

My 0.02¤ about this is that I personaly prefer a configuration script
that reflect reality, than something more "user convenient" that could
fool people about the way things work. Netfilter insides, as well as
kernel insides, are already complicated enough to me, for I do not need
stuff that could make me misunderstand something. Reality is that NAT
depends on conntrack. Your point would be to invert this for user's
sake, and this is, imho, a baaaaad thing ;)

I don't know if any of them are reading this thread, but if we could
have some core developper's point of vue about his, would be great.

It is a very tough subject to discuss how kernel configuration must be
presented. I wouldn't show nerd's behaviours, e.g. dumb users do not
compile kernel, but I tend to think that if someone wants to build its
own kernel, then it's up to him to (try to ?) understand how it is going
and what are the choices he's about to make.


Cc netfilter-devel.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: more questions about kernel config options for iptables

[Robert P. J. Day]

On 8 Apr 2003, Cedric Blancher wrote:

> Le mar 08/04/2003 à 14:23, Robert P. J. Day a écrit :
> > it would make far more sense to have a list of menu options
> > that reflects what a user would want to *do*, and have the
> > underlying dependencies kept invisible.  a more readable menu
> > like:
> > 
> >    Basic filtering
> >      Connection tracking
> >    NAT
> >    Packet mangling
> 
> This does not reflect reality. Connection tracking does not depend on
> basic filtering. It's even completly independent form it. It does not
> depend on NAT either.

sorry, i didn't mean it that way -- just suggesting that, if one
selects to do basic filtering, a sub-option of "connection tracking"
means that they want to do *additional* filtering.  but there would
still have to be a top-level connection tracking option.  this just
gets messy with these interdependencies.  yuck.
 
> > gotcha.  if you want masq/NAT, you would have to select
> > not only Connection tracking, but IPtables support and,
> > within that, "Full NAT".  and that's why i dislike the current
> > menu layout.  it would be more reasonable for someone to say,
> > "i want NAT", and have the underlying dependencies automatically
> > satisfied.
> 
> I see your point. But I do think connection tracking has to appear as a
> independent choice.

i agree.  see above.  i'll give all of this more thought, and peruse
the actual code more carefully to see how all of this ties together.

rday

Re: more questions about kernel config options for iptables

[Robert P. J. Day]

On 8 Apr 2003, Cedric Blancher wrote:

> My 0.02¤ about this is that I personaly prefer a configuration script
> that reflect reality, than something more "user convenient" that could
> fool people about the way things work. Netfilter insides, as well as
> kernel insides, are already complicated enough to me, for I do not need
> stuff that could make me misunderstand something. Reality is that NAT
> depends on conntrack. Your point would be to invert this for user's
> sake, and this is, imho, a baaaaad thing ;)
> 
> I don't know if any of them are reading this thread, but if we could
> have some core developper's point of vue about his, would be great.
> 
> It is a very tough subject to discuss how kernel configuration must be
> presented. I wouldn't show nerd's behaviours, e.g. dumb users do not
> compile kernel, but I tend to think that if someone wants to build its
> own kernel, then it's up to him to (try to ?) understand how it is going
> and what are the choices he's about to make.

yes, i agree with this.  i think i'll just ponder how to reorganize
that menu to, first of all, have more informative help screens and,
second, to add what i *think* we agree on is some missing
dependencies.  

rday

p.s.  is the rest of this list also getting auto-vacation messages
from respond-dgour?  just wondering if it's coming from *this*
list.

Re: more questions about kernel config options for iptables

[Joel Newkirk]

On Tuesday 08 April 2003 09:54 am, Robert P. J. Day wrote:
> On 8 Apr 2003, Cedric Blancher wrote:
> > My 0.02¤ about this is that I personaly prefer a configuration
> > script that reflect reality, than something more "user convenient"
> > that could fool people about the way things work. Netfilter insides,
> > as well as kernel insides, are already complicated enough to me, for
> > I do not need stuff that could make me misunderstand something.
> > Reality is that NAT depends on conntrack. Your point would be to
> > invert this for user's sake, and this is, imho, a baaaaad thing ;)
> >
> > I don't know if any of them are reading this thread, but if we could
> > have some core developper's point of vue about his, would be great.
> >
> > It is a very tough subject to discuss how kernel configuration must
> > be presented. I wouldn't show nerd's behaviours, e.g. dumb users do
> > not compile kernel, but I tend to think that if someone wants to
> > build its own kernel, then it's up to him to (try to ?) understand
> > how it is going and what are the choices he's about to make.
>
> yes, i agree with this.  i think i'll just ponder how to reorganize
> that menu to, first of all, have more informative help screens and,
> second, to add what i *think* we agree on is some missing
> dependencies.

Reorganization and clearer help texts would be nice.  If the long-term 
intention is to 'simplify', I really think a more popular approach would 
be to offer multiple levels of detail.  In my first response I suggested 
"make easyconfig" - that grew out of a conversation I had some time ago 
regarding the complexitly of configuring a kernel prior to build.  Make 
oldconfig can be helpful, but the ability to pull in the configuration 
of the current runnning kernel, set it as the base, then offer looser, 
more generalized selections that hide the lower levels would be helpful 
for the 'casual' builder.  If we want to make kernel building reasonable 
for the 'average' windows emigre then such an approach would seem 
useful.  And I think that needs to be a consideration.  I for one would 
enjoy clearer (or even extant!) help texts in the config process, and 
reorganization of options might help, but I want to have access to 
everything, not have config questions spoon-fed.

OT - are there any plans to bring video card options together, instead of 
the current scheme where they are scattered through Character Devices, 
Multimedia Devices, and Console Drivers?

> rday
>
> p.s.  is the rest of this list also getting auto-vacation messages
> from respond-dgour?  just wondering if it's coming from *this*
> list.

Yes, it is.  As of about 8 months ago I have a filter to auto-delete 
them.  Every few months they seem to start up again.  (must be nice to 
get that many vacations, some for several weeks! :^)

j

Re: more questions about kernel config options for iptables

[Robert P. J. Day]

On Tue, 8 Apr 2003, Joel Newkirk wrote:

> OT - are there any plans to bring video card options together, instead of 
> the current scheme where they are scattered through Character Devices, 
> Multimedia Devices, and Console Drivers?

<sigh>.  i was looking at that and, as i mentioned, took a crack
at reorg'ing the filesystems menu in the most recent 2.5.6x
kernels.

sadly, that was pretty easy since the Kconfig files and associated
source files were in the same directory.  so cleaning up a *single*
menu or submenu is not hard.

but it's clear that there is stuff scattered all over the menu
structure that should be related.  the difficulty there is that
different people are responsible for different subsystems,
and look after their own directory structure.  so that makes it
*way* more difficult to bring together options in distant
menus.

i'm trying to do this a little at a time; hence the attempt
to deal with the netfilter stuff as a start.  one level higher
up, it's clear that the entire networking options menu could
stand some cleaning.

rday

RE: more questions about kernel config options for iptables

[Daniel Chemko]

Yes, but it is ok. They are just letting us know that they miss not
being able to read all the juicy new iptables gossip. When they return,
I am sure they will have a nice inbox full of Iptables goodness (unless
they got fired!).

	p.s.  is the rest of this list also getting auto-vacation
messages
	from respond-dgour?  just wondering if it's coming from *this*
	list.

OT: video cards, was: more questions about kernel config options for iptables

[Arnt Karlsen]

On Tue, 8 Apr 2003 11:11:23 -0400 (EDT), 
"Robert P. J. Day" <rpjday@mindspring.com> wrote in message 
<Pine.LNX.4.44.0304081107590.11474-100000@dell>:

> On Tue, 8 Apr 2003, Joel Newkirk wrote:
> 
> > OT - are there any plans to bring video card options together,
> > instead of the current scheme where they are scattered through
> > Character Devices, Multimedia Devices, and Console Drivers?
> 
> <sigh>.  i was looking at that and, as i mentioned, took a crack
> at reorg'ing the filesystems menu in the most recent 2.5.6x
> kernels.
> 
> sadly, that was pretty easy since the Kconfig files and associated
> source files were in the same directory.  so cleaning up a *single*
> menu or submenu is not hard.
> 
> but it's clear that there is stuff scattered all over the menu
> structure that should be related.  the difficulty there is that
> different people are responsible for different subsystems,
> and look after their own directory structure.  so that makes it
> *way* more difficult to bring together options in distant
> menus.
> 
> i'm trying to do this a little at a time; hence the attempt
> to deal with the netfilter stuff as a start.  one level higher
> up, it's clear that the entire networking options menu could
> stand some cleaning.
> 

..ok, I the video newbie volonteer as guineapig with: 
Bus  1, device   0, function  0:
    VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP 
(rev 122).      
      IRQ 11.
      Master Capable.  Latency=64.  Min Gnt=8.
      Prefetchable 32 bit memory at 0xea000000 [0xeaffffff].
      I/O at 0xd000 [0xd0ff].
      Non-prefetchable 32 bit memory at 0xe9000000 [0xe9000fff].

...and:
Bus  0, device  15, function  0:
    VGA compatible controller: ATI Technologies Inc 3D Rage II+ 
215GTB  [Mach64 GTB] (rev 154).      
      Master Capable.  Latency=32.  Min Gnt=8.
      Non-prefetchable 32 bit memory at 0xe0000000 [0xe0ffffff].
      I/O at 0x6600 [0x66ff].
      Non-prefetchable 32 bit memory at 0xe1000000 [0xe1000fff].


-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

indev/outdev_name?

[Scott MacKay]

Sorry if this is more of an ebtables thing, but
probably is relevant to how the 2.5 kernel responds...

When you configure a bridge, is there any way to have
the real interface name in indev_name or outdev_name
for userspace modules?  Seeing a FORWARD packet from
"br0" to "br0" is not helpful...

Also, is there any other solution other than ebtables
to have a bridge send packets to an iptables userspace
module?

-Scott

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com