4

I have no problem finding out if a socket belongs to user space - I simply scan /proc/ to see which PID owns the [socket]. But with TCP sockets open in the kernel space there is no entry in /proc/ (since kernel has no PID). I assume that it is not safe to suppose that just because socket wasn't found in /proc, it was initiated by the kernel. I though about /proc/net/tcp's undocumented 7 columns at the end. Maybe one of them can give hints as too socket's origin? I couldn't decipher kernel's source code to figure out what those 7 fields represent.

Could someone lend me some assistance, please.

sendmoreinfo
  • 1,772
  • 13
  • 34
abirvalg
  • 41
  • 2
  • Try seeing whether `rpcinfo -p` reports information regarding those ports. – poige Oct 09 '11 at 22:14
  • Thanks for the suggestion: I ran rpcinfo -p while in-kernel socket was sending packets and clearly hitting my iptables rule for outgoing TCP. Unfortunately rpcinfo didn't show it's port number. –  Oct 09 '11 at 22:29
  • Can you clarify what you are trying to do? Or what the motivation is here to hopefully clarify what the question is? What information are you trying to gather? What do you mean by 'TCP socket is in kernel-space'? – polynomial Oct 10 '11 at 02:03

1 Answers1

2

Try netstat with additional args:

sudo netstat -wtpeav

The sudo is there to make sure you run it as root, otherwise it won't show you everything.

The options are:

-w, --raw
    Show raw sockets.

-t, --tcp
    Show TCP protocol sockets.

-p, --program
    Show the PID and name of the program to which each socket
    belongs.

-e, --extend
    Display additional information. Use this option twice for
    maximum detail.

-a, --all
    Show both listening and non-listening sockets. With the
    --interfaces option, show interfaces that are not up

--verbose , -v
   Tell the user what is going on by being verbose. Especially
   print some useful informa‐ tion about unconfigured address
   families.

Also, the columns at the end of /proc/net/tcp are documented in the kernel source tree in Documentation/networking/proc_net_tcp.txt. The end fields are:

1000        0 54165785 4 cd1e6040 25 4 27 3 -1
 |          |    |     |    |     |  | |  | |--> slow start size threshold, 
 |          |    |     |    |     |  | |  |      or -1 if the threshold
 |          |    |     |    |     |  | |  |      is >= 0xFFFF
 |          |    |     |    |     |  | |  |----> sending congestion window
 |          |    |     |    |     |  | |-------> (ack.quick<<1)|ack.pingpong
 |          |    |     |    |     |  |---------> Predicted tick of soft clock
 |          |    |     |    |     |              (delayed ACK control data)
 |          |    |     |    |     |------------> retransmit timeout
 |          |    |     |    |------------------> location of socket in memory
 |          |    |     |-----------------------> socket reference count
 |          |    |-----------------------------> inode
 |          |----------------------------------> unanswered 0-window probes
 |---------------------------------------------> uid
aculich
  • 3,610
  • 1
  • 26
  • 33
  • netstat -lptvw usually does the trick for me. – Jonathan Henson Dec 19 '11 at 02:45
  • I added `-w` to my answer since it doesn't hurt to display raw sockets, even though the question specifically mentioned TCP sockets. And `-v` also doesn't hurt. I'm not sure that `-l` is helpful in this case, though since `-a` covers both listening and non-listening sockets. – aculich Dec 19 '11 at 04:37
  • And speaking of raw sockets the page [SOCK_RAW Demystified](http://sock-raw.org/papers/sock_raw) is interesting reading. – aculich Dec 19 '11 at 05:03