[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: tracing ports open by kernel modules
From:       "Cliff Woolley" <JWOOLLEY () wlu ! edu>
Date:       1999-08-05 16:23:16
[Download RAW message or body]


>>> "Lennert Buytenhek" <buytenh@dsv.nl> 08/05/99 10:16AM >>>

>>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?
>The inodes are just sequentially assigned. Every file in an ordinary
>file system has an inode number (sort of an index). So do sockets.
[snip]
>You can find in /proc/<pid>/fd/ which 'inode' a socket
>fd links to, and then you can find in /proc/net/tcp or /proc/net/udp
which
>socket it is by comparing the inodes. (This is what fuser does then).
So
>really, there is nothing magical to the inode numbers.

Hmm... as I suspected.  So much for that idea.

>To be able to do what you want you could add a field to each socket
>(creating_pid for example) which remembers the creating pid. This
>is also tricky in a sense, in that the creating pid might have
already
>died (and sockets are passed on through fork() and you can also
>pass socket fd's over pipes, some of the lesser known and used
>features of *nix). The trouble is that this will 1. require a patched
>kernel and 2. will never be approved by Linus. I assume your app
>was intended to be a general thingy?

True on both accounts.  It works great, except it leaves a few blanks
where it knows the port/proto combination, but can't figure out what
process it is.  Maybe I just have to punt and hardcode in a message that
says "[maybe kernel-based]" if all else fails?  Or do I make dangerous
and not-portable assumptions about what ports might be what?  That'd
probably be better left in a readme.  So maybe something along the lines
of "[maybe kernel, see docs]".  That kind of takes the fun (and the
functionality) out of it.  :-/

-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/

[prev in list] [next in list] [prev in thread] [next in thread]