topic Re: Retreiving IP Address in Operating System - OpenVMS

Retreiving IP Address

Jack Trachtman — Fri, 13 Jul 2007 21:56:55 GMT

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

Re: Retreiving IP Address

Steven Schweda — Fri, 13 Jul 2007 22:24:06 GMT

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.

Re: Retreiving IP Address

Volker Halle — Sat, 14 Jul 2007 01:06:47 GMT

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.

Re: Retreiving IP Address

Robert Gezelter — Sat, 14 Jul 2007 03:35:28 GMT

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

Re: Retreiving IP Address

Jan van den Ende — Sat, 14 Jul 2007 04:18:22 GMT

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

Proost.

Have one on me.

jpe

Re: Retreiving IP Address

Robert Gezelter — Sat, 14 Jul 2007 06:40:33 GMT

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

Re: Retreiving IP Address

Jack Trachtman — Mon, 16 Jul 2007 10:44:40 GMT

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

Re: Retreiving IP Address

Jack Trachtman — Mon, 16 Jul 2007 17:22:51 GMT

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?

Re: Retreiving IP Address

Robert Gezelter — Mon, 16 Jul 2007 17:38:58 GMT

Jack,

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

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

Re: Retreiving IP Address

Hoff — Thu, 19 Jul 2007 06:57:53 GMT

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.

Re: Retreiving IP Address

Jon Pinkley — Thu, 19 Jul 2007 12:43:15 GMT

Re: Hoff's comment "packets arriving via one of the alias addresses of a NIC will be sent with the primary address of the NIC."

We aren't using the multi-IP address per NIC feature, but if it works as Hoff says, I cannot see how it would possibly work. How would a TCP connection ever be established to one of the secondary addresses?

I would expect it to work in a similar way to a secondary address on a Cisco router. Packets sent in response to connections established by other nodes would use the IP address that was connected to.

I am not sure what Jack's intentions are, but I wanted to do the same thing a long time ago, before it was possible to have multiple IP addresses on a single NIC.

Here's the scenario we wanted to address. We had an Executive Information System on the cluster. We wanted people to be able to connect to "EIS" and have sys$sylogin detect that they wanted to enter the executive friendly menu. With LAT we were able to do this with multiple service names. sys$sylogin had a program that could detect the LAT service that was connected to, and if it was EIS, they never see a DCL prompt. When we migrated off LAT, there was nothing that corresponded to that functionality. We thought of two possible workarounds, but were not able to get either to work (this was 15 years ago at another job). First thought was to somehow allow for telnet connections to multiple TCP ports in addition to the standard port 23, with the idea that we would determine the port, and therefore the "service" they were connecting to. The second was to allow multiple IP addresses, one for each service on each node, and to use DNS to forward to one of the proper addresses for that service. We would have then needed to be able to determine the IP address connected to, and determine the "service" by reverse DNS lookup.

In the end we just let login.com do different things for different users.

Re: Retreiving IP Address

Hoff — Thu, 19 Jul 2007 13:05:15 GMT

>>>We aren't using the multi-IP address per NIC feature, but if it works as Hoff says, I cannot see how it would possibly work. How would a TCP connection ever be established to one of the secondary addresses?<<<

I'd expect this is a feature of TCP connections and routing; numbers of IP hosts and addresses can be involved in a TCP connection, after all. Intermediate nodes don't care where a packet goes.

BTW, the IP address behavior with alias IP addresses is directly out of the TCP docs.

Re: Retreiving IP Address

Jan van den Ende — Thu, 19 Jul 2007 14:06:25 GMT

Jack,

I am not sure if our solution is possible in your situation, but anyway, here it is:

For one application (further details graciously left out, but is implemented as a VERY simple screen-scraper) we absolutely NEED a strict sequence of a
Uername:
prompt, an answer, and a
Password:
prompt, an answer, , and then the application announcement text.
(all system output also at fixed positions).

Fancy that with thousends of incomimg sessions, only a tiny fraction for this app.

We implemented it by directing this app at a specific service in the firewall, and NATing this service back at the VMS cluster, but "spoofing" the source address to be something specific.
Now in SYS$SYLOGIN if the source node was this special dummy source, AND the user held he appropiate identifier, then we would directly jump to the app.
We DID have to educate the users of this app, that if it did not work, they first enter any other VMS app; and change their password, or read all their new mail, or resolve ANY issue that would interfere with the "EXPECTed" sequence....

Hoping to have been of some use,

Proost.

Have one on me.

jpe

Re: Retreiving IP Address

Doug Phillips — Thu, 19 Jul 2007 19:16:39 GMT

In the end we just let login.com do different things for different users.

In the past I've used the UIC group to segregate user groups, and had something like this in sylogin.com:

$ GRP = F$GETJPI ("","GRP")
$ GROUP_LOGIN = "LOGINGRP" + F$STRING(GRP) + ".COM"
$ if f$search(GROUP_LOGIN) .NES. "" THEN @'GROUP_LOGIN'

to define various special logicals and symbols. An individual user could have even more specific def's in his/her login. Also had an option in the menu system that would allow users with higher priv's to get to the $ but keep everyone else captive.

I've used rights ID's in a similar way; usually presenting a default UI if the user doesn't hold a right, and some special UI if s/he does.

If the problem is to identify which network a user is on to segregate the users, then maybe using a similar method would work better than hard-coding IP's and having to worry about changing the code if a NIC gets replaced.

Another benefit to making things more "user" rather than "site" specific, is if a person goes to the other site and logs in he'll get a familiar UI. Of course, there could be a security down side to this, too.

Not knowing the goals, YMMV

Re: Retreiving IP Address

Jon Pinkley — Fri, 20 Jul 2007 23:33:49 GMT

After unsuccessfully trying to find the documentation about behavior of alias addresses, I did configure a several alias ip address on one of our nodes, and they appear to me to work like a secondary address on a Cisco router.

The following examples are from my testing.

Configuration tested on.

$ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4
on a AlphaServer 2000 4/233 running OpenVMS V7.3-2

$ tcpip sho interface
Packets
Interface IP_Addr Network mask Receive Send MTU

LO0 127.0.0.1 255.0.0.0 1179 1179 4096
WE0 206.157.122.24 255.255.255.0 5152457 34676 1500
$ netstat -n "-I" we0
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
WE0 1500 aa:0:4:0:17:4 5152522 0 34685 0 0
WE0 1500 206.157.122/24 206.157.122.24 5152522 0 34685 0 0
WE0 1500 172.30.200/21 172.30.200.24 5152522 0 34685 0 0
WE0 1500 172.30.200/21 172.30.207.24 5152522 0 34685 0 0
WE0 1500 172.30.200/21 172.30.207.23 5152522 0 34685 0 0
WE0 1500 206.157.122/24 206.157.122.23 5152522 0 34685 0 0
$

Specifically, output packets in response to a connection to an alias use the alias address as the source. This is true even if the alias is in the same network as the the primary.

Specific examples using telnet from ohter hosts to connect to system with telnet.(packets sent in response by local system)

Dst Address Src Address used.
206.157.123.74 172.30.207.23 (response to telnet client at 206.157.123.74 connecting to 172.30.207.23)
206.157.123.74 172.30.207.24 (response to telnet client at 206.157.123.74 connecting to 172.30.207.24)
206.157.123.74 172.30.200.24 (response to telnet client at 206.157.123.74 connecting to 172.30.200.24)
206.157.123.74 206.157.122.24 (response to telnet client at 206.157.123.74 connecting to 206.157.122.24)
206.157.123.74 206.157.122.23 (response to telnet client at 206.157.123.74 connecting to 206.157.122.23)

Note in every case the NIC uses the IP address that was connected to. This is a requirement for a tcp connection establishment three-way-handshake to work. Otherwise the node attempting the connection will receive a response from a different ip address than was connected to, and it will be ignored. NAT in between systems can make the addresses different, but from the perspective of the node establishing the connection, the IP address that sends the SYN,ACK must he identical to the IP address that the SYN packet was sent to.

Google "tcp connection handshake" and you will find plenty of info about how this all works.

The following is an example showing what the local system displays when a telnet connection from 206.157.123.74 was made to the alias address 172.30.207.23.

The following is output extracted from SDA> tcpip show dev tna31/full

Terminal TNA31: service type None, protocol Telnet
Network Device: (not connected)
Accessportname: Host: B24RTR1L Locn:
Remote address: 206.157.123.74 port 24082
Local address: 172.30.207.23 port 23

For outbound connections, the source address used appears to be the one of the following:

1. To a connected network (one for which the NIC has at least one address in) the ip address will be the IP address from that network that was the first one configured on the interface. Note that this can be an alias address.

Specific examples

Dst Address Src Address used.

206.157.122.1 206.157.122.24 (Connected network, network 206.157.122.0/24, primary IP used)
172.30.200.1 172.30.200.24 (Connected network. network 172.30.200.0/21, first configured in network used)

2. To an address that is not on a connected network, the primary address will be used as the source.

Specific examples follow, using telnet from system.

Dst Address Src Address used.

172.30.24.1 206.157.122.24 (non-connected network, primary IP used)

I am attaching a logfile with the traces captured using ethereal showing the three-way-handshake with the primary address and one of the alias addresses.

Re: Retreiving IP Address

Jack Trachtman — Mon, 23 Jul 2007 16:52:09 GMT

Thanks for all the input.

I contacted HP and found out two things:

1) The reason that Location is returned instead of Port# sometimes is that VMS requests it from clients and if that info is returned it is displayed to help locate the client for security issues

2) Other people besides myself have requested this info, so someone at HP has written a pgm just to get the info. Below is an example of usage in case anyone else would find it useful:

$ getipinfo:==$home:TCPIP$TN_SHOW.EXE_AXP;1
$ getipinfo tna1185:
Local address: 172.20.66.43, port: 23
Remote address: 172.20.69.184, port: 1821
$ sho sym tcpip$tn*
TCPIP$TN_LOCAL_ADDRESS = "172.20.66.43"
TCPIP$TN_LOCAL_PORT = "23"
TCPIP$TN_REMOTE_ADDRESS = "172.20.69.184"
TCPIP$TN_REMOTE_PORT = "1821"

Re: Retreiving IP Address

Jon Pinkley — Tue, 24 Jul 2007 22:56:59 GMT

Jack,

Is there a case number to reference if someone else with a support contract wants to request the TCPIP$TN_SHOW program?

Jon