Retreiving IP Address

[Jack Trachtman]

TCPIP V5.4

We have a VMS host w/two IP addresses. Users can telnet to the host using either address.

From within a DCL script, how can I find out which IP address is being used?

Thanks

[Steven Schweda · Accepted solution]

Crude, but potentially effective (details
left as an exercise):

alp $ write sys$output f$getdvi( "tt", "TT_ACCPORNAM")
Host: 207.90.215.17 Port: 49293

Extract the "Port:" number, and feed it into:

ALP $ tcpip show devi /full /port = 49293
Device_socket: bg6627 Type: STREAM
LOCAL REMOTE
Port: 23 49293
Host: 10.0.0.9 207.90.215.17
Service: TELNET
[...]


I'm assuming that "Host: 10.0.0.9" would
have been different if I had been coming in
through a different address.

[Volker Halle]

Jack,

$ TCPIP SHO DEV/PORT=xxx does not tell you, over which local IP address the session has been established.

But you can use the NETSTAT command (invoke @SYS$MANAGER:TCPIP$DEFINE_COMMANDS first):

The Local Address column shows the IP address, to which the session has been established (tested on TCPIP V5.6 ECO 1):

$ NETSTAT
...
tcp 0 0 nodec.23 10.20.30.150.1145 ESTABLISHED
tcp 0 0 node2.23 10.20.30.150.1146 ESTABLISHED

You for a given port number (p) use:

$ PIPE netstat | search sys$pipe .p

Volker.

[Robert Gezelter]

Jack,

Does "From within a DCL script" mean from within the logged in process, or from an external process.

Within the process F$GETDVI (for completeness the GETDVI function also available through the system service) with the TT_ACCPORNAM parameter will get that information.

A quick check on an 8.2 system verifies that that solution also works from outside the process.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Re Bob;
>>>
Within the process F$GETDVI (for completeness the GETDVI
<<<
I suspect you mean GETJPI ??

Proost.

Have one on me.

jpe

[Robert Gezelter]

Jan,

No, I did mean F$GETDVI. When I wrote the post, I was thinking of not working from the process ID. I used the logical name TT to get the terminals device name. Admittedly, there are other ways of doing this.

However, you are correct that F$GETJPI also accepts a TT_ACCPORNAM parameter, which can be used to find the name of the terminal.

- Bob Gezelter, http://www.rlgsc.com

[Jack Trachtman]

Bob, Jan,

You misread my question - I'm not trying to get the *remote* IP address, but determine which of 2 host addresses have been used to connect via Telnet.


Volker,

Your idea works, but...

I've got a GS1280 w/about 6000 IP connections. When I use a Pipe cmd to Search the Netstat output, it takes nearly 60 seconds!!! Since I need code to use within a LOGIN.COM script, this takes far too long.


Steven,

Looks like your idea, though as you say "crude", will do what I need.


Any additional ideas would be appreciated.


Thank you

[Jack Trachtman]

After more testing...

Volker - your idea does work - I needed to add the "-N" option to NETSTAT so it wouldn't try to do a reverse lookup for each of the 6000 connections.


Good news & bad news:

GN: with multiple Telnet sessions from a Windows box, I can tell which host IP address they've connected to.

BN: I need to search the NETSTAT output for both a remote host addr & its port number (I found a situation where there was a Telnet session and another type of connection, both using the same Port #!) This works for PC connections.

When I telnet from another VMS host, in that session a SHOW TERM or F$GETDVI w/TT_ACCPORNAM, instead of returning a Port #, returns a "Location" with the remote VMS system's terminal-device name followed by the userid on that box. I can't figure out how to get the Port # in this situation.

Any suggestions?

[Robert Gezelter]

Jack,

If you are working from within LOGIN.COM (or the SYLOGIN file), the F$GETDVI will work.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

I understand the immediate question around the IP address and others have addressed that, but I might ask for some background on what you are up to here.

If you're looking to map the network, for instance, there are ways and tools to approach that.

There are other potential triggers for added complexity, as well: existing IP features such as failSAFE IP and IP cluster aliases can add more "interest" to this discussion. You can also have multiple IP addresses per NIC, as well. And incoming addresses can be different than outgoing addresses; packets arriving via one of the alias addresses of a NIC will be sent with the primary address of the NIC.