This article updates my December 2002 article How to map TCP ports back to a VOS or ftServer process with new and improved ways to map a TCP port number back to a VOS STCP (15.3 or later) or ftServer Windows 2003 server process. It also adds information on finding a VOS STCP process using a UDP port and finding an ftLinux process. For information about TCP_OS, STCP before 15.3 or ftSever running Windows 2000 server refer to the original article.
Step 2 is to associate the device found in step 1 with a process. This can be done with the who_locked command (figure 3).
Note that this will NOT work with connected sockets being used by OSL since there is no associated device. A connected socket is one that is in an ESTABLISHED state. It will work for OSL sockets in a LISTEN state. You can confirm that a socket without an associated device is being used by OSL by looking for a "Q Name = osl" entry instead of a device. You can see this in figure 4. First a netstat shows that there are 3 sockets using a port number of 3005 (two local one remote). If we match on both "@" or "dv" and select the local port 3005 you can see that two socket TCBs (TCP Control Blocks) are displayed. These match up with the first column from the netstat display. However, only the first socket - the one in a LISTEN state has a device associated with it. If instead we match on "@" or "osl" we get the same two TCBs but now only the second one has a "Q Name = osl". If we match on the third socket's local port number you can see no device information is returned but there is a "Q Name = osl" line.
The second new argument, "-b" will display the PID, loaded DLLs and the name of the EXE file (figure 6).
The final argument "-v" when used with "-b" will display even more information about the components used in the EXE file (figure 7). I have no idea how Windows decides to display a loaded DDL with the -b switch or the -v switch.
You have to be patient with "-b" and "-v", it can take a while to generate the output; long enough that you may think something has gone wrong with the command.
Sometimes the command as displayed by netstat is not complete. You can get the complete command by going to the /proc/PID directory and looking at the cmdline file. Note that this file does not end in a new line so the prompt will follow the command line.
VOS (STCP - TCP))
This is now a 2 step process instead of 3 or 4 steps. The first step is to use the analyze_system request dump_stcbq to find the STCP device associated with the socket. You can specify any combination of the local and remote IP addresses and port numbers (see figure 1). IP addresses cannot be specified in dotted decimal notation; you have your choice between decimal or hex. In general I think hex is easier since each decimal portion of the IP address is converted to hex independently of the other sections. So 10.11.12.13 would be 0A0B0C0D in hex. In decimal it would be 168496141. The port numbers can be specified in decimal. Since dump_stcbq dumps a lot of information you want to filter it with match. In this case match on the string "dv" (see figure 2). Note that if there is only 1 socket with the specified port number you do not need to specify an IP address. If there is more than 1 socket with the same port number dump_stcbq will display all of them (see figure 4 for an example). It is very important to remember to use the -full argument as well. If you do not, nothing useful will be displayed.
Figure 1 - VOS analyze_system dump_stcbq request form
as: dump_stcbq -form
---------------------------------- dump_stcbq --------------------------------
-full: no
-laddr:
-faddr:
-lport:
-fport:
Figure 2 - Step 1 -- Find VOS device name with dump_stcbq
as: match dv; dump_stcbq -laddr A4984D22x -lport 22 -full
sth_dvtx = 151 (stcp.m15_9380)
Figure 3 - Step 2 -- Finding the process that owns the VOS device
as: ..who_locked #stcp.m15_9380
stcp.m15_9380:
Object is write locked by root.root (sshd) on module %phx_vos#m15
executing sshd.pm.
Figure 4 - Sockets used by OSL
netstat -number -all_sockets
. . .
8b1931c0 tcp 0 0 *:3005 *:* LISTEN
86a24040 tcp 0 0 172.16.1.116:3005 172.16.1.203:50559 ESTABLISHED
8b774680 tcp 0 0 172.16.1.116:49224 164.152.77.203:3005 ESTABLISHE
+D
. . .
as: match '@' -or dv; dump_stcbq -lport 3005 -full
*************** STCP TCB @ 8B1931C0 ************
sth_dvtx = 51 (stcp.m16_18)
*************** STCP TCB @ 86A24040 ************
as: match '@' -or osl; dump_stcbq -lport 3005 -full
*************** STCP TCB @ 8B1931C0 ************
*************** STCP TCB @ 86A24040 ************
Q Name = osl
as:
as: match '@' -or dv; dump_stcbq -lport 49224 -full
*************** STCP TCB @ 8B774680 ************
as: match '@' -or osl; dump_stcbq -lport 49224 -full
*************** STCP TCB @ 8B774680 ************
Q Name = osl
as:
VOS (STCP - UDP)
This is a multistep process requiring that you manually follow pointers. The first step is to get the PCB address. You do this with the netstat command. I'll use port 58686 as an example, its PCB address is fe6e0700. The next step is to dump the PCB and find the qptr value. Then dump the stream associated with that qptr to get the q_next pointer. Follow that by dumping the stream assocaited with the q_next value but now you can match on the "dv" string to get just the device name (just like the TCP socket at this point). Finally we can do a who_locked on the device to find out who is using it.
Figure 5 - Finding the owner of a UDP socket
netstat -numeric -protocol udp -PCB_addr -all_sockets
Active connections (including servers)
PCB Proto Recv-Q Send-Q Local Address Foreign Address (state)
fe6f8600 udp 0 0 *:161 *:*
fe6f8800 udp 0 0 *:7 *:*
fe6fa000 udp 0 0 *:9 *:*
. . .
fe6f4100 udp 0 0 164.152.77.34:123 *:*
fe6ee200 udp 0 0 172.16.1.34:123 *:*
fe6f3b00 udp 0 0 *:58682 *:*
fe6f3d00 udp 0 0 *:58683 *:*
fe6e8600 udp 0 0 *:58684 *:*
fe6e9c00 udp 0 0 *:58685 *:*
fe6e0700 udp 0 0 *:58686 *:*
ready 10:51:23
as: match qptr; dump_oneucb fe6e0700
ub_qptr 87E8D400
as: match
as: match q_next; dump_stream -queue 87E8D400
q_next = 87E8D240
as: match dv; dump_stream -queue 87E8D240
sth_dvtx = 172 (udp.m15_58695)
as:
as: ..who_locked #udp.m15_58695
udp.m15_58695:
Object is write locked by Noah_Davids.SysAdmin (radius_auth_server) on
module %phx_vos#m15 executing radius_auth_server.pm.
as:
ftServer (2003)
Windows 2003 and Windows XP have added 3 control arguments to the netstat command. The first "-o" will display the PID of the controlling process (figure 5). Once you have the PID you can use taskmanager to map the PID to an EXE file. I don't recommend this approach, why do in two steps what you can do in one? Note to get the sockets in a LISTEN state you need to use the "-a" argument.
Figure 6 - Windows netstat -nao - to display the sockets owners PID
C:\Documents and Settings\Noah Davids>netstat -nao
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING 1844
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 1844
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1056
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 1844
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1048 0.0.0.0:0 LISTENING 1844
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 976
. . .
Figure 7 - Windows netstat -nab - to display the sockets owner's PID, components and EXE
C:\Documents and Settings\Noah Davids>netstat -nab
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING 1844
[inetinfo.exe]
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 1844
[inetinfo.exe]
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1056
c:\windows\system32\WS2_32.dll
C:\WINDOWS\system32\RPCRT4.dll
c:\windows\system32\rpcss.dll
C:\WINDOWS\system32\svchost.exe
C:\WINDOWS\system32\ADVAPI32.dll
[svchost.exe]
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 1844
[inetinfo.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
[System]
TCP 0.0.0.0:1048 0.0.0.0:0 LISTENING 1844
[inetinfo.exe]
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 976
-- unknown component(s) --
C:\WINDOWS\system32\ole32.dll
[svchost.exe]
. . .
Figure 8 - Windows netstat -nabv - to display even more
C:\Documents and Settings\Noah Davids>netstat -nabv
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING 1844
C:\WINDOWS\system32\WS2_32.dll
C:\WINDOWS\System32\inetsrv\ISATQ.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
C:\WINDOWS\System32\inetsrv\ftpsvc2.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
C:\WINDOWS\System32\inetsrv\ftpsvc2.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
[inetinfo.exe]
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 1844
C:\WINDOWS\system32\WS2_32.dll
C:\WINDOWS\System32\inetsrv\ISATQ.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
C:\WINDOWS\System32\inetsrv\w3svc.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
C:\WINDOWS\System32\inetsrv\w3svc.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
[inetinfo.exe]
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1056
c:\windows\system32\WS2_32.dll
C:\WINDOWS\system32\RPCRT4.dll
c:\windows\system32\rpcss.dll
C:\WINDOWS\system32\svchost.exe
C:\WINDOWS\system32\ADVAPI32.dll
[svchost.exe]
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 1844
C:\WINDOWS\system32\WS2_32.dll
C:\WINDOWS\System32\inetsrv\ISATQ.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
C:\WINDOWS\System32\inetsrv\w3svc.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
C:\WINDOWS\System32\inetsrv\w3svc.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
[inetinfo.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
-- unknown component(s) --
[System]
TCP 0.0.0.0:1048 0.0.0.0:0 LISTENING 1844
C:\WINDOWS\system32\WS2_32.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
C:\WINDOWS\System32\inetsrv\ftpsvc2.dll
C:\WINDOWS\System32\inetsrv\inetinfo.exe
[inetinfo.exe]
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 976
-- unknown component(s) --
C:\WINDOWS\system32\ole32.dll
[svchost.exe]
. . .
ftLinux
On ftLinux you can use the "-p" argument with netstat to get the process ID (PID) and command associated with each ESTABLISHED and LISTEN socket (you need to use "-a" to get LISTEN sockets). You have to be root in order for this to work (figure 8). If you are not root you get an error message before the display. If there is a lot to display, the warning will scroll off the top of your window so you may miss it. The key is just a "-" where the PID/Command should be (figure 9).
Figure 9 - ftLinux netstat -nap - to display PID and command line executed as root
[noah@164dhcp-1707-13092 ~]$ sudo netstat -nap | grep tcp
tcp 0 0 0.0.0.0:1152 0.0.0.0:* LISTEN 5026/ftltrapsubagen
tcp 0 0 0.0.0.0:384 0.0.0.0:* LISTEN 5010/ftlsubagent
tcp 0 0 0.0.0.0:199 0.0.0.0:* LISTEN 4995/snmpd
tcp 0 0 0.0.0.0:777 0.0.0.0:* LISTEN 4835/rpc.statd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 4816/portmap
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 5131/sendmail: acce
tcp 0 0 0.0.0.0:764 0.0.0.0:* LISTEN 5249/sra_ssn
tcp 0 0 ::ffff:127.0.0.1:32781 :::* LISTEN 5273/java
tcp 0 0 :::22 :::* LISTEN 5065/sshd
tcp 0 48 ::ffff:164.152.76.141:22 ::ffff:164.152.77.50:2857 ESTABLISHED 20077/sshd: noah [p
Figure 10 - ftLinux netstat -nap - to display PID and command line executed as regular user
[noah@164dhcp-1707-13092 ~]$ netstat -nap | grep tcp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:1152 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:384 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:199 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:777 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:764 0.0.0.0:* LISTEN -
tcp 0 0 ::ffff:127.0.0.1:32781 :::* LISTEN -
tcp 0 0 :::22 :::* LISTEN -
tcp 0 0 ::ffff:164.152.76.141:22 ::ffff:164.152.77.50:2857 ESTABLISHED -
Figure 11 - Displaying the process' complete command line
[noah@164dhcp-1707-13092 5065]$ cd /proc/20077
[noah@164dhcp-1707-13092 20077]$ cat cmdline
sshd: noah [priv][noah@164dhcp-1707-13092 20077]$
Send comments and suggestions
This page was last modified on 08-09-18
to ndav1@cox.net