views:

499

answers:

6

Is there a Linux library that will enable me to tell what IP sockets are owned by what processes? I guess I'm looking for the programmatic equivalent of lsof -i. Ultimately, I want to correlate packets seen through libpcap to processes.

UPDATE: A couple of people have suggested using /proc/<pid>/net/tcp and udp, but on my system, the same data is shown for every process, so it doesn't help.

+1  A: 

I'd go to the source:

http://ubuntuforums.org/showthread.php?t=1346778

DaveC
+3  A: 

You can read them from proc filesystem. The 'files' you probably want to look at are found in /proc/<pid>/net (namely tcp, udp, unix)

Here's some examples on using the proc filesystem

Kimvais
+1 really useful ... thanks :)
Michel Kogan
Perhaps I'm missing something, but /proc/*/net/tcp shows the same data for different pids. Must be showing all connections. How can I map each one back to the source pid?
Rob H
+2  A: 

The /proc filesystem provides details on each process, including networking information. Open socket information is listed in /proc/net/tcp. The IPv6 sockets are listed separately in the tcp6 file. The socket information includes information such as the local and remote ports, and the socket inode number, which can be mapped back to the process by parsing the /proc/{pid}/fd/* information.

If you aren't familiar with the /proc filesystem, it is basically a virtual filesystem that allows the kernel to publish all sorts of useful information to user-space. The files are normally simple structured text files that are easy to parse.

For example, on my Ubuntu system I used netcat for testing, and ran nc -l -p 8321 to listen on port 8321. Looking at the tcp socket information:

$ cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 00000000:2081 00000000:0000 0A 00000000:00000000 00:00000000 00000000  1000        0 26442 1 de0c8e40 300 0 0 2 -1                             
   1: 0100007F:0277 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 7019 1 de0c84c0 300 0 0 2 -1                              

The first line shows it is listening on all addresses to point 8321 (0x2081). The inode number is 26442, which we can use to look up the matching pid in /proc/{pid}/fd/*, which consists of a bunch of symlinks from the file handle number to the device. So if we look up the pid for netcat, and check its fd mapping:

$ ls -l /proc/7266/fd
total 0
lrwx------ 1 gavinb gavinb 64 2009-12-31 09:10 0 -> /dev/pts/1
lrwx------ 1 gavinb gavinb 64 2009-12-31 09:10 1 -> /dev/pts/1
lrwx------ 1 gavinb gavinb 64 2009-12-31 09:10 2 -> /dev/pts/1
lrwx------ 1 gavinb gavinb 64 2009-12-31 09:10 3 -> socket:[26442]

And there we see that file descriptor 3 in this process is mapped to the socket with inode 26442, just as we expect.

So obviously to build a complete map of sockets, you will need to first enumerate all the /proc/**/fd/* files, look up the socket symlinks, then match the socket inode against the tables from /proc/net/tcp which has the endpoint information.

This is the the way the lsof tool works (see lsof/dialects/linux/dsocket.c for the implementation).

gavinb
Same question as I had for Kimvais: The /proc/*/net/tcp directories show the same data for different pids. How can I map each one back to the source pid?
Rob H
I have updated the answer to include a full description of how to map sockets to pids. I hope this is clearer now - it basically involves building a table of pids to socket inodes, and looking up these inodes in the tcp socket table. Let me know if there's anything that needs clarifying.
gavinb
Very clear. Thanks!
Rob H
+1  A: 

You could try running lsof with strace and see just which files in /proc it gets data from.

Mike K
straight to the point
Matt Joiner
+5  A: 

I think you first have to look through the open fds in /proc/*/fd, e.g.

4 -> socket:[11147]

and then look for the referenced sockets (by the inode) in /proc/net/tcp (or /proc/net/udp), e.g.

12: B382595D:8B40 D5C43B45:0050 01 00000000:00000000 00:00000000 00000000  1000        0 11065 1 ffff88008bd35480 69 4 12 4 -1
cmeerw
This is the missing link. Thanks! (Won't let me upvote for some reason.)
Rob H
You answered this while I was writing, and I didn't notice... good job :) +1 since OP apparently can't.
ephemient
A: 
ephemient