Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I have a Slackware 10.2 install, and my kernel is version 2.6.17, built from source.
I've been playing around some with iptables, but I'm missing some extensions. So I loaded in the Slackware source for iptables and attempted to build it, telling it where my kernel source is as per INSTALL instructions.
The compile breaks when it encounters ipt_string.c. Seems there it's trying to use struct ipt_string_info, but that's nowhere to be found. I've monkeyed around with it a little bit by trying to write my own header file to define that struct going by how the .c file is using it, but I've not had much luck with that.
IMHO, I should not have to write this header myself (not that I could get that to work anyway. . . ). Has anyone else run across this? And if so, how did you get around it?
Alright, I've download the latest iptables (3.3.5) and patch-o-mattic, applied the patch, re-compiled the kernel, compiled and installed iptables.
Now I'm having a problem that started out similar to this thread, where htb was having a problem with string matching and specifying the --algo parameter. So I handled that by specifying --algo bm. Now it gives me this error:
iptables: Unknown error 4294967295
I know this is not a whole lot of information to go by, but does anyone have any ideas as to what to do next?
Did a little research and there saw some suggestions about using the raw table for string matching. Tried that, and got an error about the raw table not existing and to try insmoding the module.
So I looked at the kernel configuration, and decided to check ALL the iptables options to build into the kernel (not as modules. (I know, probably not a great idea. I'll go back and check just what I need later on). This old machine does not have a lot of processor power or memory, so it took several hours to compile the new kernel. I had to go to bed while it was still working.
Tonight, I'll install the new kernel and try again.
FYI, I installed my new kernel and retried the string match. Still got an error about the raw table not existing. So I tried putting it on the standard filter, specified --algo bm, gave it a nice hot cup of tea, and it worked!! I was able to stop a web page on my local server from coming up when the words "go away" were anywhere on the page, while other pages showed up fine. When I removed the filter, the "go away" page worked again!
My next personal task is to fix ipt_string.c to default to the bm algorithm, so that it does not have to be specified, as apparently was the case in earlier versions of iptables.