linux-2.6.9-rc1 compilation and configuration issue (fwd)

linux-2.6.9-rc1 compilation and configuration issue (fwd)

[James B. Hiller]

Hi!

No takers?  Or have I put this in the wrong forum?  If I have, please
let me know where to go with it.

thx,
jbh

Forwarded message:
> From jhiller Sun Sep  5 19:18:57 2004
> Subject: linux-2.6.9-rc1 compilation and configuration issue
> To: netfilter@lists.netfilter.org
> Date: Sun, 5 Sep 2004 19:18:57 -0400 (EDT)
> X-Mailer: ELM [version 2.5 PL6]
> Content-Length: 4371      
> 
> Hi list!
> 
> Hope someone in netfilter-land will take pity on the village idiot here,
> and explain what I'm seeing.  It's either bugs or a stupid-user stupid
> selections of kernel netfilter compilation options.
> 
> I'll pose my questions first, then provide some (hopefully) useful background
> and observation info.
> 
> Questions (all related to linux 2.6.9-rc1):
> 
> a.  Should it be the case that by simply selecting Networking Support,
> Networking Options, Network Packet Filtering, Netfilter Configuration
> (all just configurator choices), and finally Connection Tracking (i.e.
> choosing Y for it, but none of the subordinate protocol choices) - and
> NO other netfilter options - that a compilation error should result?
> I did, and it does.  Is this a bug, or is there known to be some other
> set of one or more options that I would have to select in order to not
> get a compilation error?
> 
> b.  Should it further be the case that the ONLY netfilter option that can be
> selected that allows for a clean compile given (a) is Full NAT?  I tried
> everything else, and this is all that allows an error-free compile given
> (a).  That is, iff (Full NAT = 'Y') && (Connection Tracking = 'Y'), I get a
> clean compile, regardless of what other netfilter/connection tracking or
> netfilter/Full NAT settings I have as 'Y'.
> 
> c.  Finally, should it be the case that if I select ONLY these two options,
> or any other set of options (such as 3 of the connection tracking protocol
> options; a robust set of match support options, and one or two of the NAT
> options; and every subset of these that I tried, which is many), that I
> should expect my system to more or less stop responding to any keyboard
> input, and fail to cause most (but not all, right away) display updating
> to stop; and eventually (within a few minutes) expect everything on the
> system to stop?  I did, and it does, and I am sore confused.
> 
> I am confused for the following reasons (observations):
> 
> 1.  I am using the exact same .config that I used for 2.6.8.1 and all the
> related -mmX releases, as modified by the 'make oldconfig' action at each
> version promotion and accepting only the default answer for the few new
> options introduced across those promotions.  ALL kernel versions previous
> to 2.6.9-rc1 worked with this more-or-less identical netfilter configuration,
> back through around 2.4.20 (all regular tree and -mmX tree) when I first
> started using netfilter a lot.
> 
> 2.  On this particular box, I make no attempt to invoke a firewall-like script,
> turn on any behaviors via echoing to /proc/sys/XXXX, or the like.  So as
> far as I know, I have been/should be enabling kernel support for these
> netfilter actions, but not actually invoking any.  Thus, I'm at a loss to
> understand why a kernel configuration that worked before stops working now,
> and when I roll back all useful options other than turning connection
> tracking on, it won't even compile right.
> 
> I've got copies of each of my various .config files at each step, and can
> easily recreate them, and the situations described, for each kernel version.
> Just not attaching them now until some kind soul says they need to inspect
> them, so as to not clog the list.
> 
> Please let me know, off-list if more appropriate, what's likely happening
> here - whether I'm seeing bugs that are worth reporting, or whether I'm
> simply ignorant of how to correctly select a proper set of options relative
> to 2.6.9-rc1.  Or maybe some bug in previous versions that let me operate
> in a stupid configuration was fixed with this release, and I'm now affected
> by my all-along stupid choices.
> 
> One last piece of context:  The box on which I'm doing this is itself one
> node on a wireless LAN, the gateway/router/WAP for which is another linux box
> running 2.6.0 and the firewall script found in the IP-Masquerade-HOWTO (as
> published prior to the current Nov 03 release of the HOWTO), as well as NAT as
> found in 2.6.0.  I know one solution would be to simply not configure netfilter
> on this box that is an internal node.  However, I do have reasons that I prefer
> to keep it configured as closely as possible to the gateway node (the
> differences being those options that are more newly available in more recent
> kernel versions, which, up until the advent of 2.6.9-rc1, seemed to be not
> an issue).  More importantly, if what I am staring at is bugs, then I would
> like to properly report them for resolution.
> 
> Thx!
> jbh
> 
> 

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Jason Opperisano]

On Tue, 2004-09-07 at 19:33, James B. Hiller wrote:
> Hi!
> 
> No takers?  Or have I put this in the wrong forum?  If I have, please
> let me know where to go with it.

i'm not really qualified to answer this question, (which has never
stopped me before)...and hey--beggars can't be choosers...  ;-)

> > 
> > Hope someone in netfilter-land will take pity on the village idiot here,
> > and explain what I'm seeing.  It's either bugs or a stupid-user stupid
> > selections of kernel netfilter compilation options.
> > 
> > I'll pose my questions first, then provide some (hopefully) useful background
> > and observation info.
> > 
> > Questions (all related to linux 2.6.9-rc1):

2.6.9-rc1 seems pretty bleeding edge...  the 2.6 series has kind of
become a test branch as it is, but sheesh--that's really out there.  do
you have a "gotta have it" reason to run this kernel?  if not--i'd say
stick with the "release" version:  2.6.8.1...  seems these kind of
compilation issues would be par-for-the-course on an "rc" kernel.

anyways...if you must--you should probably be following the
netfilter-devel list (and linux-kernel for that matter)--check out the
post from Harald Welte (with patch):

http://marc.theaimsgroup.com/?l=netfilter-devel&m=109346594923412&w=2

-j

-- 
Jason Opperisano <opie@817west.com>

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[James B. Hiller]

Hi Jason.

> On Tue, 2004-09-07 at 19:33, James B. Hiller wrote:
> > Hi!
> > 
> > No takers?  Or have I put this in the wrong forum?  If I have, please
> > let me know where to go with it.
> 
> i'm not really qualified to answer this question, (which has never
> stopped me before)...and hey--beggars can't be choosers...  ;-)

You bet.  Thanks for giving it a throw.

> 2.6.9-rc1 seems pretty bleeding edge...  the 2.6 series has kind of
> become a test branch as it is, but sheesh--that's really out there.  do
> you have a "gotta have it" reason to run this kernel?  if not--i'd say
> stick with the "release" version:  2.6.8.1...  seems these kind of
> compilation issues would be par-for-the-course on an "rc" kernel.

With maybe one or two exceptions beginning in late 2.4.X when I started
using rc's and mmX, no, clean compilation hasn't been an issue.  My main
reason for moving with each change is that for about a year, I've been
working with a developer who's trying to get DMA-related bugs out of
the switch from using SCSI emulation to having SCSI handling built into
the IDE driver.  Until that's done, I can't use DMA with my CD writer,
where before I could.  His bugfixes have been going into 2.6.7+, a bit at
a time, through the mm branch.

> anyways...if you must--you should probably be following the
> netfilter-devel list (and linux-kernel for that matter)--check out the
> post from Harald Welte (with patch):
> 
> http://marc.theaimsgroup.com/?l=netfilter-devel&m=109346594923412&w=2

Thx!  I haven't been looking at netfilter-devel, since until now, it was
a non-issue for me.  What that particular item, and a few after it, show
is that indeed there is a known issue both with NAT in general and
double NAT in 2.6.9-rc1; and that the hang I'm getting is affecting others
as well.  So that tells me I don't need to try to report it; I'm not using
a dumb netfilter configuration; and that it may get better in -rc2++.  Since
my DMA issue isn't done yet anyway, no harm in laying back from -rc1.

I really appreciate the pointer!

regards,
jbh

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Aleksandar Milivojevic]

James B. Hiller wrote:
> Hi!
> 
> No takers?  Or have I put this in the wrong forum?  If I have, please
> let me know where to go with it.

Wish I could help you.  But I never seem to get past the point of even 
applying the patches ;-)

Sure, those I don't need apply clean, those that I'm interested in like 
tcp windows tracking always fail.

BTW, why do we need to recompile entire kernel and iptables, just to get 
one tiny miny module installed?  It kind of beats the hole idea of 
modularity and loadable modules, isn't it?  (well, at least half of the 
idea behind it, anyhow) Why can't we just compile two source files and 
place resulting object files into appropriate directories 
(kernel/iptables version independent)?  And not to have to worry about 
recompiling them when new kernel release is out there.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Jose Maria Lopez]

El mié, 08 de 09 de 2004 a las 16:10, Aleksandar Milivojevic escribió:
> James B. Hiller wrote:
> > Hi!
> > 
> > No takers?  Or have I put this in the wrong forum?  If I have, please
> > let me know where to go with it.
> 
> Wish I could help you.  But I never seem to get past the point of even 
> applying the patches ;-)
> 
> Sure, those I don't need apply clean, those that I'm interested in like 
> tcp windows tracking always fail.
> 
> BTW, why do we need to recompile entire kernel and iptables, just to get 
> one tiny miny module installed?  It kind of beats the hole idea of 
> modularity and loadable modules, isn't it?  (well, at least half of the 
> idea behind it, anyhow) Why can't we just compile two source files and 
> place resulting object files into appropriate directories 
> (kernel/iptables version independent)?  And not to have to worry about 
> recompiling them when new kernel release is out there.

Patches changes the source code of the kernel and iptables in a lot
of places, not just a modular place in the code you can separate from
the rest, that's why you can't patch code from modules or pieces of
code, because many places in the code are changed when you apply the
patches.

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Jose Maria Lopez]

El mié, 08 de 09 de 2004 a las 20:23, Aleksandar Milivojevic escribió:
> Jose Maria Lopez wrote:
> > Patches changes the source code of the kernel and iptables in a lot
> > of places, not just a modular place in the code you can separate from
> > the rest, that's why you can't patch code from modules or pieces of
> > code, because many places in the code are changed when you apply the
> > patches.
> 
> Which is probably the reason why some of the patch-o-matic patches are 
> failing to install with some versions of kernel, and other patches are 
> failing to install with some other versions of kernel.  If the things 
> were designed the right way from the day one, we wouldn't need to 
> download xyz MB of kernel source, install development environment, 
> compilers and stuff, going through the hussle of recompiling the kernel, 
> ....  Instead of just downloading one or two additional kernel modules 
> (couple of kB) that we really need (in either source or object format), 
> and there would be no need to recompile them when upgrading the kernel. 

I don't think that could be possible in any way, not even trying it from
the very day one of the development of the kernel. It's like hoping that
new patches to upgrade the kernel only touch some very modular parts of
the kernel so you don't have to recompile all the kernel to upgrade it.
Some changes in some subsystems, and you can bet the networking one it's
one of the most complex, need changes in many parts of the kernel code.
The kernel is modularized now in almost every way it can be done, but
there are things simply impossible.

>   That was one of the things in which Solaris is light years ahead of 
> Linux (sorry to have to say that, but it's the hard truth).

I don't see the difference with Solaris. If you want to upgrade your
Solaris you have to apply a lot of upgrades, also to the kernel. That's
the impression I have from the little contact I had with Solaris.

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Aleksandar Milivojevic]

Jose Maria Lopez wrote:
> Patches changes the source code of the kernel and iptables in a lot
> of places, not just a modular place in the code you can separate from
> the rest, that's why you can't patch code from modules or pieces of
> code, because many places in the code are changed when you apply the
> patches.

Which is probably the reason why some of the patch-o-matic patches are 
failing to install with some versions of kernel, and other patches are 
failing to install with some other versions of kernel.  If the things 
were designed the right way from the day one, we wouldn't need to 
download xyz MB of kernel source, install development environment, 
compilers and stuff, going through the hussle of recompiling the kernel, 
....  Instead of just downloading one or two additional kernel modules 
(couple of kB) that we really need (in either source or object format), 
and there would be no need to recompile them when upgrading the kernel. 
  That was one of the things in which Solaris is light years ahead of 
Linux (sorry to have to say that, but it's the hard truth).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Aleksandar Milivojevic]

Jose Maria Lopez wrote:
[snip]
> there are things simply impossible.

Impossible? There's no such thing ;-)

> I don't see the difference with Solaris. If you want to upgrade your
> Solaris you have to apply a lot of upgrades, also to the kernel. That's
> the impression I have from the little contact I had with Solaris.

Not really.  Solaris (well, SunOS actually) has "disadvantage" of being 
closed-source.  So Sun had to publish API and document data structures 
garanteed not to change in set period of time (as defined in Solaris 
device driver development guides).  That allows for a third party to 
provide loadable kernel module that works with current version of 
Solaris kernel (both generic and patched), and possibly future versions 
of Solaris kernel (up to some point).  Of course, if developer doesn't 
wonder into the undocumented land ;-)  More than once I used kernel 
module compiled for previous version of Solaris (one was driver for 
Sun's unfortunate BigMac ethernet card, don't remember exatly what the 
others were).

If there was such a thing in Linux kernel, bringing some of the new 
features might be a bit slower and harder task for core Linux developers 
(you can't just change that function call, or data structure), but on 
the other hand some of the "impossible" to implement features would 
become "possible"...

Becoming way off topic, anyhow...

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Cedric Blancher]

Le mer 08/09/2004 à 20:23, Aleksandar Milivojevic a écrit : 
> ....  Instead of just downloading one or two additional kernel modules 
> (couple of kB) that we really need (in either source or object format), 
> and there would be no need to recompile them when upgrading the kernel. 

That would imply that everybody would have the same kernel, which is far
from being the case, from one distro to another, and from one's build to
other's, for anyone can build its own kernel, with its own options,
optimizations and architecture.

>   That was one of the things in which Solaris is light years ahead of 
> Linux (sorry to have to say that, but it's the hard truth).

The hard truth is that Solaris is closed source and has a few
architectures to maintain. Which means they just have to produce a
couple of modules to please their all users. If you consider a single
Linux distro, it will be the same. You can download packages, that
contains binary modules, and they will install just fine, just like
Solaris. But just like for Solaris, you will only have features
maintainers consider relevant for you.


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Jose Maria Lopez]

El mié, 08 de 09 de 2004 a las 21:00, Aleksandar Milivojevic escribió:
> Jose Maria Lopez wrote:
> [snip]
> > there are things simply impossible.
> 
> Impossible? There's no such thing ;-)
> 
> > I don't see the difference with Solaris. If you want to upgrade your
> > Solaris you have to apply a lot of upgrades, also to the kernel. That's
> > the impression I have from the little contact I had with Solaris.
> 
> Not really.  Solaris (well, SunOS actually) has "disadvantage" of being 
> closed-source.  So Sun had to publish API and document data structures 
> garanteed not to change in set period of time (as defined in Solaris 
> device driver development guides).  That allows for a third party to 
> provide loadable kernel module that works with current version of 
> Solaris kernel (both generic and patched), and possibly future versions 
> of Solaris kernel (up to some point).  Of course, if developer doesn't 
> wonder into the undocumented land ;-)  More than once I used kernel 
> module compiled for previous version of Solaris (one was driver for 
> Sun's unfortunate BigMac ethernet card, don't remember exatly what the 
> others were).
> 

The same can be said for the Linux kernel, for a version of the kernel
you can have binary modules given by any vendor. The kernel structures
doesn't change much between the same kernel tree. Normally a distributor
can give source code for a kernel module that can be compiled for any
of the versions of the same kernel tree. One example of this is VMWare
and the kernel modules it needs, they give you some compiled binary
modules for some kernel versions, and the source code that can be
compiled.

> If there was such a thing in Linux kernel, bringing some of the new 
> features might be a bit slower and harder task for core Linux developers 
> (you can't just change that function call, or data structure), but on 
> the other hand some of the "impossible" to implement features would 
> become "possible"...
> 

But then we won't have so many upgrades in the kernel, and some of
this upgrades are needed, because some of them are for bugs. What
does Sun do when they found a bug in the kernel? They probably give
their customers a kernel upgrade. The same can be said for Linux, but
with more frequent upgrades. You have to choose, having stability in
the kernel structures to have third party modules easy to deliver or
having new features more frequently.

> Becoming way off topic, anyhow...
-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[James B. Hiller]

Hi!

> Jose Maria Lopez wrote:
> [snip]
> > there are things simply impossible.
[snip snip]
> 
> Becoming way off topic, anyhow...

Well, actually, not really - from following a post that Jason provided me
yesterday in response to my re-posted question, you can easily see how
the modularity/patching issue is to some degree a factor in the behavior
I was asking about.

Here was Jason's post to me; notice the post he references:
---------------------------------------------------
On Tue, 2004-09-07 at 19:33, James B. Hiller wrote:
> Hi!
> 
> No takers?  Or have I put this in the wrong forum?  If I have, please
> let me know where to go with it.

[snip]

2.6.9-rc1 seems pretty bleeding edge...  the 2.6 series has kind of
become a test branch as it is, but sheesh--that's really out there.  do
you have a "gotta have it" reason to run this kernel?  if not--i'd say
stick with the "release" version:  2.6.8.1...  seems these kind of
compilation issues would be par-for-the-course on an "rc" kernel.

anyways...if you must--you should probably be following the
netfilter-devel list (and linux-kernel for that matter)--check out the
post from Harald Welte (with patch):

http://marc.theaimsgroup.com/?l=netfilter-devel&m=109346594923412&w=2
-----------------------------------------------------

If you follow that one backward and forward, you'll see other very
related patch/modularity discussion, and how the issue most likely
influences exactly what I asked about.

And also note that it became a topic on both the netfilter-devel list
and the linux-kernel list.

So... I'd say, not OT that much, or even at all!

BTW - from the info in that thread, I more or less got the answer I was
trying to get:  my config choices most likely should be expected to work;
it's principally an issue with this particular release; and I should expect
that it will get better.

thx,
jbh

Re: linux-2.6.9-rc1 compilation and configuration issue (fwd)

[Aleksandar Milivojevic]

Jose Maria Lopez wrote:
> But then we won't have so many upgrades in the kernel, and some of
> this upgrades are needed, because some of them are for bugs. What
> does Sun do when they found a bug in the kernel? They probably give
> their customers a kernel upgrade. The same can be said for Linux, but
> with more frequent upgrades. You have to choose, having stability in
> the kernel structures to have third party modules easy to deliver or
> having new features more frequently.

Sun produces a patch for a bug that doesn't break existing third party 
modules (and, usually, same is true for Linux).  And it doesn't require 
you to recompile any third party modules after you install it.  Sun 
kernel patches include the kernel core itself, and if bugs were in 
modules, it also includes the modules that need to be patched (for bugs, 
not for changes in kernel core).

As for the other issue, in production environment I'd choose stability 
over bleeding edge features anytime.  Updating kernel on my home machine 
is one thing (if something gets screwed up, no web surfing for one 
afternoon, big deal).  Updating tens or hundreds or thousands of 
production machines is something completely different.  Anyhow, what I 
was aruging is that since SunOS is closed source, they were forced to do 
modularization of kernel "the right way".  Linux being open source had 
freedom of not doing it the right way (well, from developers perspective 
it might be also called the right way, but not from the end-user's 
perspective).  And Linux abused that freedom...  So now, instead of just 
getting tcp_windows_trackign.c, compiling against linux26 kernel header 
files (that would be static for entire 2.6.x tree) and dropping 
resulting tcp_window_tracking.ko into /lib/kernel26/net/ipv4/netfilter 
(with kernel26 being shared by all 2.6.x kernels), I need to recompile 
and reinstall entire damn kernel.  Not to mention downloading the entire 
kernel source that I really don't need...

In SunOS/Solaris world, Netfilter developers would be forced to use that 
approach/design.  In Linux world they unfortunately had Linux source 
code available ;-)

The way it is now, I first need to discover to which kernel version I 
can actually apply tcp_window_tracking patch.  Tried several, failed on 
all of them.  At the end I just gave up, and am waiting for stable 
kernel that will have it already applied...  Darn...

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7