Operating System - OpenVMS
1752407 Members
5537 Online
108788 Solutions
New Discussion юеВ

Re: How to determine to which IP address a process connected

 
SOLVED
Go to solution
Volker Halle
Honored Contributor
Solution

Re: How to determine to which IP address a process connected

Jim,

if you want to, you can get the remote port number for the TNA device from SDA:

$ ANAL/SYS
SDA> TCP SHOW DEVICE TNA36:/FULL

Terminal TNA36: service type None, protocol Telnet
Network Device: (not connected)
Accessportname: Host: axpvms.invenate.local Locn: _TNA56:/HALLE
Remote address: 10.20.30.203 port 52980
Local address: 10.20.30.200 port 23
...

Volker.
Jim Geier_1
Regular Advisor

Re: How to determine to which IP address a process connected

This looks promising, but I am not getting success with the TCP command in SDA on Alpha or on Integrity:

$ analyze/system
OpenVMS system analyzer
SDA> tcp show device tna11:/full
%CLI-W-SYNTAX, error parsing 'TCP'
SDA>

How does one get access to that "TCP" command in SDA?
Volker Halle
Honored Contributor

Re: How to determine to which IP address a process connected

Jim,

I'm sorry, this was a typo ;-(

Try

SDA> tcpip show device tna11:/full

If the first token on the SDA command line is not a recognized command within SDA, it will try to find a SDA extension and invoke that. SDA looks for extensions under SYS$SHARE:xxx$SDA.EXE.

In this case, there is no TCP$SDA.EXE, but a TCPIP$SDA.EXE.

Volker.
Jim Geier_1
Regular Advisor

Re: How to determine to which IP address a process connected

The SDA TCPIP command works every time in all situations in which I have tried it. Below is the DCL script I put together. Note that when in SDA, the command
TCPIP SHOW DEVICE _TNA111: /FULL produces:
%TCPIP-E-NOTBGDEVICE, Not a BG (INET network socket) device
-TCPIP-E-NOTTNDEVICE, Not a TN (network terminal) device

but TCPIP SHOW DEVICE TNA111: /FULL (without the leading underscore) works just fine.

$! CONNECTED_IP.COM
$! Get the IP address to which the session connected on this system
$
$ tna_device = f$getjpi(0,"tt_phydevnam") - "_"
$ if f$extract(0,3,tna_device) .nes. "TNA" then exit
$ proc_name = f$getjpi(0,"prcnam")
$ sda_file = f$parse(f$unique(),"sys$scratch:.tmp")
$ tna_file = f$parse(f$unique(),"sys$scratch:.tmp")
$ open/write sda$file 'sda_file'
$ write sda$file "$ analyze/system"
$ write sda$file f$fao("set output !AS",tna_file)
$ write sda$file f$fao("tcpip show device !AS /full",tna_device)
$ write sda$file "exit"
$ close sda$file
$ define/user_mode sys$output nla0:
$ @'sda_file'
$ open/read tna$file 'tna_file'
$TNA_LOOP:
$ read/end_of_file=tna_done tna$file record
$ record = f$edit(record,"trim,compress")
$ if f$extract(0,13,record) .nes. "Local address" then goto tna_loop
$ ip_address = f$element(2," ",record)
$ write sys$output f$fao("Process !AS connected to IP address !AS",-
f$getjpi(0,"prcnam"),ip_address)
$TNA_DONE:
$ close tna$file
$ delete 'tna_file'
$ delete 'sda_file'
$ exit
Jim Geier_1
Regular Advisor

Re: How to determine to which IP address a process connected

The bad thing about this solution is that SDA required CMKRNL privilege. So this solution is not going to work as a means to detect during the system-wide login the ip address to which a user has connected.
Hoff
Honored Contributor

Re: How to determine to which IP address a process connected

>The bad thing about this solution is that SDA required CMKRNL privilege. So this solution is not going to work as a means to detect during the system-wide login the ip address to which a user has connected

Here's an example of how to do a DECnet connection to connect to a server process using just DCL:

http://labs.hoffmanlabs.com/node/1524

This target server process can execute (using a proxy) and return the data.

There are other ways to resolve this, and without passing out CMKRNL.

A somewhat sneaky (and fully documented) approach is to set CMKRNL in the default mask but not the authorized mask, and to then strip off the privilege after you're done with it in LOGIN or SYLOGIN. Add a CTRL/Y block in the UAF flags, and you're good to go.

It's also not particularly difficult to implement this via available (installed) code, but that's more work than the above approaches. Presuming you can't locate somebody that's implemented this and posted it.