IPTables 1.3.x fails on RaQ2

I've been trying to figure out why the current iptables fails on the 2.6.9 and 2.6.11 MIPS builds. It seems that a file cpu-features-overrides.h is missing for the Cobalt builds. Are their plans for one, or is there a patch out there so we can get it added. Here is the error message on the IPTables build, I still don't understand why they are checking for that myself.

# ./iptables install
       Verifying iptables-1.3.1.tar.bz2
               Downloading iptables-1.3.1.tar.bz2
               Creating Local SHA1 file for iptables-1.3.1.tar.bz2
               Installing iptables-1.3.1
                       Unpacking iptables-1.3.1.tar.bz2
Making dependencies: please wait...
Something wrong... deleting dependencies.
make: *** [cpu-feature-overrides.h] Error 1
               -----Error at Build has occured-----
Exiting

----
Jim Gifford
[email protected]

Jim,

I am running iptables-1.2.11-r3 on my Gentoo installed Cobalt Qube2 and it compiles alright. If I remember correctly I have tried a higher version which failed on cpu-feature-overrides.h too.

My kernel is linux-2.6.10-20050115 which is in the Portage tree of Gentoo and is based upon CVS. So far this machines runs for 14 days without a problem.
It runs iptables with shorewall.

Regards,

Tom

This is a headers problem, mainly in 2.6. 2.6 isn't safe out-of-the-box for userland consumption. I've been toying with some 2.6.10 headers from LMO cvs on the gentoo side of things, where we have an "appCompat" patch that plugs up a alot of the leaky holes in 2.6.x headers, but I still have to analyze the patch and add in some mips-specific bits before these headers can be considered remotely sane for even testing.

Those running other distros will probably need similar modifications to their headers to make them userland-friendly.

--Kumba

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond

I just don't understand why iptables needs that file at all, I can't find anything in it that uses it. I'm going to search again, and I will post my results once I figure it out.

iptables doesn't need it. It's one of those funky #include chains. include A includes B which includes C which includes Q and so on until it tries including a file it can't find. This is because there are a series of mach-* machine subdirs in include/asm-mips that each contain headers specific to a particular machine type (like spaces.h, among other things). I haven't delved into the specifics (someone else here can explain it more), but when the kernel builds, based upon the configuration of the kernel, it knows which include/asm-mips/mach-* directory to look in to snag the headers it needs. Userland doesn't know this, so for headers used in userland, you need to patch things abit. Otherwise, they break.

http://tinyurl.com/5grah <-- appCompat patch used in Gentoo's linux-headers 2.6.10 ebuild. It lacks mips-specific bits, but you can look at how x86 handles some of its include/asm-i386/mach-* sections for how we're working around these issues. It's all a hack really, until someone either fixes userland to never use kernel headers, or the kernel-side finds a way to create userland-friendly headers (but I don't see any of this happening anytime soon).

--Kumba

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond

I do not use linux-headers-2.6.x on my Qube2, but iptables still b0rked on anything higher then 1.2.11-r3. If I am correct then mips-headers is the equivelant of linux-headers? In that case I have 2.4.21-r3.

My Qube2 acts as my firewall and so I have tried several versions the first time I installed it. At that time iptables wasn't marked stable on mips.

I found the culprit, but don't know what the proper fix is.

File - What to remove or comment out /usr/src/linux/include/asm/cpu-features.h - #include <cpu-feature-overrides.h> /usr/src/linux/include/asm/addrspace.h - #include <spaces.h>

But it still fails, because it looks at the headers in /usr/include and the ones is /usr/src/linux/include, which is what the problem is. Namely socket.h

What I noticed is some of the mips architectures includes have these files and some do not.

A workaround for those who use the linux-libc-headers to build iptables with the following commands, but I would still comment out those files to prevent other build issues later

make KERNEL_DIR=/usr

But I'm not sure of the stability and the functionality.

----
Jim Gifford
[email protected]

These headers are search along a search path until found. Typically that path consists of two directories such as mach-ip22 followed by mach-generic as last. This allows eleminating duplicated header files.

A bad side effect - users frequently forget adding files such as cpu-features-override.h which contain a detailed description of the CPU properties on a particular platform. Without a platform specific file the kernel will basically fallback to generic code that is slow but supports almost every CPU in the universe.

Ralf

Ralf and other Linux-MIPS readers,
I checked the linux-libc-headers for those files, and they are not
there. I'm tried fighting this battle with netfilter before and they won't budge from the fact that they build iptables from the headers in /usr/src/linux, if you use my make KERNEL_DIR=/usr, the problem doesn't exist it's only when we build from the raw kernel headers. So what method is the proper method, building from the raw headers or santized ones like linux-libc?

----
Jim Gifford
[email protected]

The sucky but official policy Linus has given out is that userland should not include kernel headers. Which means anything else is ok.

Ralf

You need to patch the headers for these things -- i.e.:

#include <cpu-feature-overrides.h>

becomes

#include <asm/mach-generic/cpu-feature-overrides.h>

Same goes for references to spaces.h, and most other files directly referenced as '#include <file.h>' in 'include/asm-mips/*'. mach-generic is best suited for this despite the actual machine because these are geared for userland, and userland shouldn't really care about what particular mips machine it's running on.

--Kumba

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond