rexec hangs or fails on attempt to access OpenVMS Alpha

[Bill Pedersen]

While trying to integrate a Linux based web app with a VMS system on a different domain I have run into a problem where rexec fails to make a connection. Now I had done this several years ago without issue but the two systems were on the same domain. This time the two systems are on different domains. I am hampered a bit as I do not have a shell account on the Linux box so some of my testing has been with W2K rexec. Everything is being handled via PHP on the Linux box.

Now, before you go and suggest SSH, which would be nice, I do not control the Linux environment so I do not have the ability to add SSH subsystem to the PHP environment on the system. If I did I would and use it. Using SSH via a system() call is a option but the configuration concerns me running from the web server environment. Getting it configured only using PHP is going to be a neat trick though and I have not worked it all out.

I have tested W2K rexec to a VMS I64 system without issue - on the same domain.

I have tested the Linux rexec to another Linux box without issue.

In my testing I have been able to get a similar response to a VMS VAX system which is behind a firewall where port 512 is open to "allow" rexec to work. But I can not get it to work, W2K rexec hangs in that case, too. With some reading this lead me to suspect the need for port 113 to be available - ident. Added that port, same behavior W2K hangs and Linux just does nothing.

If anyone has any experience or suggestions I would appreciate it.

I do have a work around - ftp. But it changes the operation from being one which is event driven to being a polled environment, albeit the polling need only occur on the VMS Alpha system looking for a new file in a given directory.

Thanks in advance for any suggestions.

Bill.

[Steven Schweda]

Around here, rlogin and rsh connections get
logged to the operator:

%%%%%%%%%%% OPCOM 22-NOV-2008 15:29:52.36 %%%%%%%%%%%
Message from user INTERnet on ALP
INTERnet ACP RSH Accept Request from Host: 10.0.0.38 Port: 1015

%%%%%%%%%%% OPCOM 22-NOV-2008 15:30:50.25 %%%%%%%%%%%
Message from user INTERnet on ALP
INTERnet ACP RLOGIN Accept Request from Host: 10.0.0.38 Port: 1013

I'd guess that rexec would do something
similar. Are you seeing any evidence of a
connection attempt? If not, then I'd look at
routing or firewall problems. Is the remote
system really using rexec(), or should you be
opening ports like 513 (rlogin) or 514 (rsh),
too/instead?

> With some reading this lead me to suspect
> the need for port 113 to be available -
> ident.

Reading what? I don't see much evidence for
my VMS system listening to it.

[Bill Pedersen]

Steven:

No evidence of loginfailures. Opcom is silent there.

Yes, I too think it is a firewall issue.

As regards to port 113 I picked that up from a discussion of a similar problem as to access to a Windows environment where they they discussed the identd daemon no Windows. Was not sure if a similar issue could have existed on VMS and since it did not solve the problem this issue was moot.

I do believe it is rexec on the client side as that is what I have issued both on Linux and W2K. So, yes I believe it is really rexec and not rsh or rlogin.

Thanks for your suggestions.

Bill.

[Hoff]

Get shell access to the Linux box (point out to whomever is blocking this that this decision costing them) and use ping and traceroute on this, and also confirm that the intervening firewalls are either open to the connection or VPN'd or vLAN'd.

Credentials are cleartext in the rexec scheme.

ftp is hideous around firewalls. Not my choice, for many reasons. If you want to tussle with something, make it sftp and ssh.

And the credentials are cleartext with ftp.

If you can't touch the Linux system, a vLAN or VPN might be an option.

But you need to run tests end-to-end and using the boxes involved.

[Wim Van den Wyngaert]

rexec uses a 2nd connection. On VMS this is a port from 1023 going down until 1 is free. It is us3ed for stderr.

Wim

[Wim Van den Wyngaert]

Some rexec versions have the option -c to avoid this extra connection. stder is then put in stdout.

Wim

[Bill Pedersen]

Wim:

Thanks for the information.

I will look into this. And see if they are blocking the outbound ports. It would not need to be an inbound port so the firewall should be ok still, at least I would expect that.

Bill.

[Wim Van den Wyngaert]

The length of the hang could also help us find why it's in hang (it should timeout).

Wim

[Bill Pedersen]

Wim:

The length of the hang on the W2K laptop to the VMS system has been "forever" - 10s of minutes. I did move the PC to the "DMZ" position on my router and got a different condition:

C:\plato\Lab Systems>rexec 194.38.185.6 -l 'username' dir
Password (194.38.185.6:):
194.38.185.6: INTERnet ACP AUXS failure
rexec: can't establish connection

This error came back within about a minute.

As you can see the ACP responded. So this suggests there might be something else going on with the W2K system. So I plan on testing without the router later today.

I have a note out to my ISP to see if they have any suggestions. I also have a note out to the folks who make my router, it is an Airlink 101 running on a 3G wireless network, to see if they have any insite, too.

Thanks for your thoughts and suggestions.

Bill.

[Wim Van den Wyngaert]

This error is normally given when rexec daemon on VMS is missing. Use tcpip$config to enable the service.

I would expect that VMS gave back an ICMP saying "service unreachable" but I tested it and it didn't. I got a timeout after 30 seconds or so.

Wim