Programmatically enumerate open sockets

[chorneck]

Does anyone know of a way to programmatically enumerate all of the open sockets in OpenVMS? I'd like to be able to write a C program that can produce output that is similar to netstat.

Regards,
chorneck

[Steven Schweda]

I don't, but you might look at using
$DEVICE_SCAN to provide a list of all the
BG* devices. Then, perhaps, some $GETDVI
magic would reveal the inner secrets of a
particular BGxxx device (perhaps some
DEVDEPENDx item code or other).

[Richard Whalen]

You didn't say what IP stack you are using.

For MultiNet and TCPware this can be done with IO$_SENSEMODE calls, the details of which can be found in the programmer's guides. I don't know what mechanism to use for TCP/IP Services. If you want to do it in a completely portable manner, then the TCP and UDP tables in SNMP have the information provided that an SNMP agent is active on the system.

[Hoff]

Eh? Please consider adding a few more words around the background and the question? This, and some details on the version and the platform?

Why do I ask? Current TCP/IP Services has a netstat tool.

$ netstat -?
ddcu:[dir]tcpip$netstat.exe;1: illegal option -- ?
usage: netstat [-AanXx] [-f address_family]
[-abgHilmMNnPrsuv] [-f address_family] [-p protocol]
[-acdntz] [-I interface] [interval]
$

This and other common tools are available after invoking sys$startup:tcpip$define_commands.com

As an alternative approach to a host-based port scan, I'd probably aim nessus or nmap or other such at the box.

[chorneck]

I apologize for being vague with my question. I wasn't sure what details were relevant. I am used to working with UNIX, so OpenVMS is a bit of a struggle for me.

>You didn't say what IP stack you are using.

We are running OpenVMS Alpha 8.3 with HP TCP/IP Services 5.6.


>Eh? Please consider adding a few more words around the background and the question?

Basically, what I'm trying to do is write a JNI library that can retrieve a list of open sockets so that this information can be consumed by our java system management agent. I mentioned netstat because it's a tool that is familiar to most and I noticed that it was available as part of the TCP/IP services.


Based on what I have come up with from my research so far, it looks like SNMP might be the only way to do this with TCP/IP services.


Regards,
chorneck

[Hein van den Heuvel]

Maybe just spawning 'netstat' and parsing its output is a reasonable thing to do for your application?

As long as you do not ned that data more than say once a minute the overhead is probably acceptable.

fwiw,
Hein.

[Richard J Maher]

His views on the ITRC points system are well known, but I am suprised you only gave Steven S two points for what, IMHO, is the correct answer.

What does his strategy (possibly in combo with io$_sensmode for what's not available with $getdvi) not give you?

Cheers Richard Maher

[Wim Van den Wyngaert]

Note that a "netstat" or "netstat -a" will do a DNS lookup for every IP address (could be thousands). Better to use "ucx show dev" or "netstat -n" to avoid this.

Wim

[Richard W Hunt]

You could also spawn a command

$ TCPIP SHOW DEVICE_SOCKET

and trap the output, which is columnar and suitable for simple-minded (fixed-column extraction) parsing. The device names will be BGxxxx, which you can then look up through GETDVI functions. The last column will tell you whether the socket is actually connected to something external, usually just by IP address rather than a reverse lookup (at least on my system.)

In GETDVI, you can then see if there is an owner process ID, in which case there will be an owner process name and owner UIC.

OK, I'm somewhat of a script fanatic, but I do a somewhat more detailed version of this in DCL with the combination of three commands:

$ TCPIP SHOW DEVICE_SOCKET
$ SHOW DEVICE/FULL BG
$ SHOW USER/FULL

(with appropriate output capture, of course) and then use DCL symbol substitution to correlate the BG devices with each other to show the open ports, partner ports where a connection exists (i.e. not just listening but active), connect type, protocol type, owner, image name, process name, IP address, and a bunch of other data. OK, probably could have done it a thousand other ways, but did it in DCL because of the ability to more easily see intermediate data when debugging. There is enough data among the output of those three commands to really tie it all together into a neat, if VERY LONG, display.

[Richard J Maher]

Nah, honestly Steven Schweda gave you the answer. Really truly! It's called programming. Something that's not done much on VMS anymore but give it a go; you might like it.

Oh I get it, this is just a wind up to get someone to write the code for you?

What's next? A Perl or Python script to parse the output from some dodgy pipe command? I'm sure we can get a couple of REGEXes in there and maybe some bash scripting to go along with the DCL? This is a System Managers dream!

Regards Richard Maher