Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
Try seeing whether rpcinfo -p reports information regarding those ports. –  poige Oct 9 '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. –  user97340 Oct 9 '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 2:03

1 Answer 1

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

-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

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
share|improve this answer
netstat -lptvw usually does the trick for me. –  Jonathan Henson Dec 19 '11 at 2: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 4:37
And speaking of raw sockets the page SOCK_RAW Demystified is interesting reading. –  aculich Dec 19 '11 at 5:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.