Yes, that is exactly what I meant. I just said IP because I was
generalizing... ie, the mechanism should work regardless of what
higher-level proto is used, TCP, UDP, RAW, whatever. So ignore that
part.
As for inetd.conf, assuming inetd is running, it's a good starting
place, as ports will be open that don't necessarily map to any process
except inetd when no connections are open. That's why I use that...
just to ferret out which program it will END UP being when the
connection gets opened.
>> The only part I haven't figured out is for ports open by the
kernel.
>> Where can I get the type of information that fuser will return for
user
>>processes for these modules? Take kernel-based NFS as an example...
it
>>seems to show up with its own PID, and I can make a fairly educated
>>guess that 800/udp maps to it, but that's not exactly definitive.
>"netstat -at" or "netstat -au"? Just my educated guess.
I'm already using netstat. It's the basis of the whole thing. Based
on that, I know which ports are open and therefore which ones to
analyze. It's just that I need to match up the port with a PID, which
netstat doesn't seem to want to do with these kernel processes (trying
'netstat -anp' you just get a - where the process name should be), and
fuser won't for kernel processes because... (see below).
>> Checking the /proc/<pid> information for that process yields
>>virtually nil. Is there are reason for this?
>Yes, there is a reason. /proc/<pid> for _that process_? What
>process are you referring to? knfsd, is this a process? (could
>be, I don't run it). Well, that's probably because kernel threads
>don't need fds. Generally, kernel threads don't have fds (they
>surrender their 'file' state with an exit_files (I believe) when they
>go kernel-thread.) Kernel threads just request raw sockets from
>the networking layer (struct socket I believe) and they use them
>to read/write etc. They do not need referring fds. (When a write
>or read from userspace comes in, first the corresponding 'struct
>file' is sought for that fd, and when it is a socket the
>corresponding 'struct socket' is looked up, and this one is
>passed down the kernel.).
That would be a good reason. :( Hmmm.... I don't guess there's any
way to keep track of which module answers which port, then. Yuck.
>You could go dig in /proc for open networking sockets (maybe
>/proc/net/tcp or /proc/net/udp gives you what you want? Try
>/proc/net/raw for raw IP sockets. There are also IPv6 versions
>if you have 2.2/2.3) but you will not find them under /proc/<pid>/fd/
>etc. because these sockets you are looking for have no fd's.
That's the same problem again... Digging in /proc/net/[tcp|udp], I *do*
find the ports in question, and an inode that they belong to... but I
can't seem go glean anything useful from the inode number. Thoughts?
What exactly does it represent?
Thanks again,
Cliff
Cliff Woolley
Central Systems Software Administrator
Washington and Lee University
http://www.wlu.edu/~jwoolley/
Work: (540) 463-8089
Pager: (540) 462-3472
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/