How to Find Out What Program's on The Other End of a Local Socket

how do I find out what program's on the other end of a local socket?

ss -p

will tell. (Provided the socket is not owned by the kernel itself.)

Identify other end of a unix domain socket connection

Update: It's been possible to to do this using actual interfaces for a while now. Starting with Linux 3.3, the UNIX_DIAG feature provides a netlink-based API for this information, and lsof 4.89 and later support it. See https://unix.stackexchange.com/a/190606/1820 for more information.

Is it possible to find which user is at the other end of a localhost TCP connection?

On Linux, /proc/net/tcp contains information on the open TCP sockets on the system. For a connected socket, the entries look like this (the header is part of the file, other lines removed):

  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     

11: 0100007F:C9CB 0100007F:0016 01 00000000:00000000 00:00000000 00000000 1000 0 978132 ...

The second and third columns have the endpoints of the socket, and the uid column has the effective UID of the process what created the socket.
/proc/net/tcp6 is similar for IPv6. (The IP address there is 127.0.0.1, so the octets seem to be in reverse order.)

If you wanted to track the actual process(es) holding the socket, you'd need to go through all /proc/$PID/fd/$N entries, and compare the inode numbers in the socket symlinks to the inode number mentioned in the tcp socket table. But you can only see the file descriptors of your own processes, unless you're the superuser.

How do I find out which process is listening on a TCP or UDP port on Windows?

PowerShell

TCP

Get-Process -Id (Get-NetTCPConnection -LocalPort YourPortNumberHere).OwningProcess

UDP

Get-Process -Id (Get-NetUDPEndpoint -LocalPort YourPortNumberHere).OwningProcess

cmd

 netstat -a -b

(Add -n to stop it trying to resolve hostnames, which will make it a lot faster.)

Note Dane's recommendation for TCPView. It looks very useful!

-a Displays all connections and listening ports.

-b Displays the executable involved in creating each connection or listening port. In some cases well-known executables host multiple independent components, and in these cases the sequence of components involved in creating the connection or listening port is displayed. In this case the executable name is in [] at the bottom, on top is the component it called, and so forth until TCP/IP was reached. Note that this option can be time-consuming and will fail unless you have sufficient permissions.

-n Displays addresses and port numbers in numerical form.

-o Displays the owning process ID associated with each connection.

How the clients (client sockets) are identified?

The server listens on an address and port. For example, your server's IP address is 10.0.0.1, and it is listening on port 8000.

Your client IP address is 10.0.0.2, and the client "connects" to the server at 10.0.0.1 port 8000. In the TCP connect, you are giving the port of the server that you want to connect to. Your client will actually get its own port number, but you don't control this, and it will be different on each connection. The client chooses the server port that it wants to connect to and not the client port that it is connecting from.

For example, on the first connection, your client may get client-side port 12345. It is connecting from 10.0.0.2 port 12345 to the server 10.0.0.1 port 8000. Your server can see what port the client is connecting from by calling getpeername on its side of the connection.

When the client connects a second time, the port number is going to be different, say port 12377. The server can see this by calling getpeername on the second connection -- it will see a different port number on the client side. (getpeername also shows the client's IP address.)

Also, each time you call accept on the server, you are getting a new socket. You still have the original socket listening, and on each accept you get a new socket. Call getpeername on the accepted socket to see which client port the connection is coming from. If two clients connect to your server, you now have three sockets -- the original listening socket, and the sockets of each of the two clients.

You can have many clients connected to the same server port 8000 at the same time. And, many clients can be connected from the same client port (e.g. port 12345), only not from the same IP address. From the same client IP address, e.g. 10.0.0.2, each client connection to the server port 8000 will be from a unique client port, e.g. 12345, 12377, etc. You can tell the clients apart by their combination of IP address and port.

The same client can also have multiple connections to the server at the same time, e.g. one connection from client port 12345 and another from 12377 at the same time. By client I mean the originating IP address, and not a particular software object. You'll just see two active connections having the same client IP address.

Also, eventually over time, the combination of client-address and client-port can be reused. That is, eventually, you may see a new client come in from 10.0.0.2 port 12345, long after the first client at 10.0.0.2 port 12345 has disconnected.

Can I find the port number if I only have the SOCKET?

There are two functions that do exactly what you want:

  1. getpeername - gets the information about the other end of the TCP connection
  2. getsockname - gets the information about the socket (local end) for both TCP and UDP


Related Topics



Leave a reply



Submit