Hi,

I was just wondering if using a non-smp kernel would be ok on a older p4 system with no x. I am wondering due to some functionality in IPTABLES that is broken in the SMP kernels ( -m owner --sid.pid,cmd-owner).

Could someone that is running a NON-SMP kernel advise as to whether the support for -m owner --cmd-owner is working in iptables with those kernels? Also, could someone advise me if running a NON-SMP kernel is even advisable? The machine will not have x.

SMP is for multi-processor systems, which you don't have anyway. There is no problem running a SMP kernel on a single processor system, but no advantage either.

1 members found this post helpful.

is there a way to find out if the ipables functionality would be available in a non-smp kernel? or is that covered in the "no advantage either" comment?

if it's 'broken' then it's a bug? perhaps in the version of the kernel you are using? Try a different kernel version or find out why it's not working the way you expect it to.

0 members found this post helpful.

Its not a bug. However In the SMP kernel the function I want is broken. Its caused by the way the kernel manages PID's. In non-smpo kernels the -m owner --cmd-own ( sid, pid ) should still work. I just wanted to know if anyone is using a non-smp kernel AND if that filter is still available in it. Based on my research so far, since the release of the smp kernels the owner module for iptables has had only partial functionality. In short, conntracking via PID, SID, and/or command name does not function due to the way the kernel tracks processes. However, if you run a non-smp kernel, this will work. Thanks though.

Just run your SMP kernel with "maxcpus=0" (on the kernel line on your bootloader). This is a special case that instructs the kernel to run as if it was a non-SMP kernel.
Easy to test.

1 members found this post helpful.

OK!! THanks!! My other question is regarding iptables itself. The online man pages reference the -m owner --cmd-owner flag; however, the ubuntu man page does not even mention it. Also, if it was indeed broken, iptables would not kick it back as an unknown right? I guess it would be better to know before installing a system just to get that functionality. Are there switches that would disable this when iptables is compiled? Has that flag been dropped from iptables all together? Google is just showing me the same reference to the command, most recent man page was from last year.

For a more complete answer to that you'll have to be more explicit about what you mean by "older p4 system" and "ok" for that matter.

if you mean "out of the P4 systems, it is one of the earlier of those", there probably isn't an issue with that part. If, on the other hand, you just meant "those p4 systems, they are pretty old by now and I have one of those systems, but it is one of the more recent ones of that collection of old systems" then there may be an issue worth considering.

The more recent P4s have the possibility of hyperthreading and while this isn't two cores, from a software point of view in runs like two cores. Thus, I believe you need an SMP kernel to utilise hyperthreading. Hyperthreading may not be a requirement for you as the performance impact is variable, but you ought to consider it before you decide.

Of course, it may well be "OK" in this application even if the performance is significantly lower.

1 members found this post helpful.

Well, that is true. A HT processor would need an SMP kernel, but it is also true that performance gains would likely be negligible anyway on a simple install with no X. But it is something the original poster would need to consider.

1 members found this post helpful.

The cpu does not support hyper threading. I had considered that before looking at this option. I just am trying to find out if the functionality is indeed available in iptables once i do switch to a non-smp kernel. It would help loads just to know where to see if ip[tables can be compiled with / without the options i am looking for. Maybe a maintainer has a non-smp and smp kernel ( like slackware ) that has iptables compiled to be compatible with both smp and non-smp kernels. I just need to be able to filter traffic based on PID on the local machine.

Thanks for all the input though.

o yeah, i just noticed how stuck up my last post may have looked....didnt mean it that way. I have just been searching alot trying to find out if iptables gets compiled with a few extra options when its run on a non-smp kernel. I do really appreciate the input!!

Can't comment for anyone else, of course, but, for me, the stuck-up-o-meter didn't even flicker. Maybe I've been hanging out in wrong places recently.

On the more serious front, the 'how pid numbering occurs on multi-processor and mono-processor systems and the knock-on effects on iptables modules' I can confidently say that you are beyond anything that I have direct knowledge of. I'm guessing that many other people will be in the same boat. As this is a bit of a drift from what seemed to be the original focus of the thread, you might try:

• changing the thread title to represent this changed focus
• starting a new thread explicitly about this issue somewhere outside 'Linux General'

this is everything other than a guarantee of success with that route as it is something of specialist question and you'd probably be better finding something like a specialist iptables mailing list, but it might just work.

Another line of attack might be to question why you need to use that particular module (part of conntrack?). Maybe there is some other way of achieving the desired goal.

1 members found this post helpful.

cool. very helpful. I am just trying to monitor traffic on a machine by the actual command vs. the port number. conntrack_ftp will track and allow traffic for ftp; however, * and i have a thread about this part ) torrent's are proving to be a pain. I dont like a policy of ACCEPT on any chain/table. So, since I cant seem to track connections with conntrack_ftp, then I must find another way. I have yet to see anything that does this ( i am sure it exist though ). I may be wrong. Filtering traffic in this way may be a really bad idea. I honestly dont know. Any way, i have looked at automated scripts to do this and none of them address issues with unprivileged port request from local host by process. I am getting ready to join a netfilter list ( thanks for that...never thought of it ).

You can get something vaguely related to what you want from iotop. Maybe iostat gets close too (or iftop...that looks promising, but I haven't much used it), but either should give you 'nearly' but not 'exactly'. Can you work round only getting roughly what you want, but getting that easily, or do you have to have exactly what you want?

1 members found this post helpful.

no such thing as getting exactly what i want i guess. I will have to take a look at those commands you listed and see if I can get it to work. Thanks for the input!! At risk of getting flagged for posting the same topic from another post: What i really want is to filter request TO REMOTE peers using bittorent. However, I would rather keep all my tables defaulted at DROP. Unfortunately, the bittorrent "protocol" may share OUT and retrieve tracker info on a dedicated port,but no dedicated port for the actual traffic. Since peers can set any number of ports to serve up shares, I cant see how to filter it for ACCEPT.
Back on topic though. The -m owner --cmd-owner flag looks useful to me. However, due to my lack of experience, I am not sure if it is a good idea to filter that way ( assuming running a non-smp kernel will even allow that ). I just dont have the experience right now.