telnet server stops accepting external connections

[Captain Harlock]

I have openvms running on simh with all license paks installed.

Everything works great, I can telnet in locally and externally.

I'm having a problem where after a short time of the vax server being
online, it stops accepting external telnet connections

From the console, if I log in, I can TELNET 0 and it connects fine, but
trying from the host or from an external computer stops working after 15
minutes or so, even though I can connect just fine earlier

If I shut down simh and restart, I can connect externally for a short time
again

Is this a known issue? Have I missed some sort of configuration?

Thanks for your help

[Stephen Hoffman]

You might want to mention a few more details...
Such as whether this configuration is using, maybe an Ubuntu instance
running as a guest on AWS, or some other configuration.
...Also if you're using static IP addresses or trying to run OpenVMS
VAX via DHCP. (DHCP tends to be sketchy in general, and particularly
as far back as OpenVMS VAX.)
...Also what version of TCP/IP Services and OpenVMS VAX are in use. $
UCX SHOW VERSION and $ SHOW SYSTEM /NOPROC
...Also what the local network looks like, as both AWS and more than a
few local networks can be complex, and emulation adds to the complexity
...Does SHOW INTRUSION show any activity around security evasion and related?
...If there's anything interesting in the telnet server log related to
the failure. That's usually in the login directory for the username
associated with the telnet server.
...Also whether setting keepalives on the telnet connections avoids the
hang. That tends to keep some intervening boxes from "forgetting" the
connection.

Why asking version and configuration information? There are some
nasty telnet bugs in certain and particularly older versions of TCP/IP
Services, too. TCP/IP Services V5.0A had a nasty one for instance,
where an interrupted telnet connection caused the telnet server to go
compute bound. Stuff as far back as VAX tends to be much more work —
there are Alpha emulators around — and networking on emulators tends to
be complex. Emulators running on hosts that are running as VM guests
out in AWS with a dollop or two of who-knows-what networking gear and
who-knows-what network traffic hitting telnet tends to be more complex.


--
Pure Personal Opinion | HoffmanLabs LLC

[David Froble]

Perhaps check for a licensing issue. You may be limited in the number of
interactive processes at the same time.

[Captain Harlock]

Yes, the ubuntu instance is on aws.

I have 2 "elastic ips", and 2 network interfaces on the instance.

eth0 is for the ubuntu instance.
eth1 is not configured for ubuntu at all, it is only raised with "ifconfig
eth1 up" but does not get a static or dhcp address in ubuntu.

simh is called using the mac address of the eth1

simh ini:

LOAD -r /home/vax/data/ka655x.bin
ATTACH nvr /home/vax/data/nvram.bin
SET RQ0 RA90
SET RQ1 RA90
SET RQ2 RA90
ATTACH RQ0 /home/vax/data/VMS-RQ0.dsk
ATTACH RQ1 /home/vax/data/VMS-RQ1.dsk
ATTACH RQ2 /home/vax/data/VMS-RQ2.dsk
SET RQ3 RRD40
ATTACH RQ3 /home/vax/data/cd.iso
SET RL DISABLE
SET TS DISABLE
SET CPU 64M
SET CPU IDLE=VAX
set xq mac=06:36:7f:ee:6c:e3
attach xq eth1
SET CPU CONHALT
DEP BDR 0
BOOT CPU
EXIT

here is my ifconfig -a on ubuntu:



eth0 Link encap:Ethernet HWaddr 06:85:c3:84:99:53
inet addr:172.31.0.50 Bcast:172.31.15.255 Mask:255.255.240.0
inet6 addr: fe80::485:c3ff:fe84:9953/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1
RX packets:4044 errors:0 dropped:0 overruns:0 frame:0
TX packets:3813 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:865007 (865.0 KB) TX bytes:906403 (906.4 KB)

eth1 Link encap:Ethernet HWaddr 06:36:7f:ee:6c:e3
inet6 addr: fe80::436:7fff:feee:6ce3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:874 errors:0 dropped:0 overruns:0 frame:0
TX packets:829 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:43203 (43.2 KB) TX bytes:60116 (60.1 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:190 errors:0 dropped:0 overruns:0 frame:0
TX packets:190 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:16115 (16.1 KB) TX bytes:16115 (16.1 KB)

the following are the openvms commands you asked about:

$ UCX SHOW VERSION

Compaq TCP/IP Services for OpenVMS VAX Version V5.1
on a VAXserver 3900 Series running OpenVMS V7.3

$ SHOW SYSTEM /NOPROC
OpenVMS V7.3 on node AEVAX 21-AUG-2016 19:20:01.58 Uptime 0 03:29:29
$ SHOW INTRUSION
%SHOW-F-NOINTRUDERS, no intrusion records match specification


openvms tcpip configuration *is* dhcp, because i have no clue what the
proper settings are for "routing" and "bind"

i know that the eth1 external ip is 1.1.1.1 (obviously ive blanked it out)
i know that the eth1 internal ip is 172.31.106.69

just for information sake, here is 'SHOW ROUTE' from openvms

TCPIP> show route

DYNAMIC

Type Destination Gateway

AN 0.0.0.0 172.31.96.1
AH 127.0.0.1 127.0.0.1
AN 172.31.0.0/16 172.31.106.69
AH 172.31.106.69 172.31.106.69

does any of this help you help me? :)

thanks for your time

[Stephen Hoffman]

On 2016-08-21 19:59:03 +0000, Captain Harlock said:

> Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>> On 2016-08-21 18:10:25 +0000, Captain Harlock said:
>>
>>> I have openvms running on simh with all license paks installed.

Okay, PAKs are not involved.

>>> Everything works great, I can telnet in locally and externally.
>>>
>>> I'm having a problem where after a short time of the vax server being
>>> online, it stops accepting external telnet connections

Which usually means a network issue.

>>> From the console, if I log in, I can TELNET 0 and it connects fine, but
>>> trying from the host or from an external computer stops working after
>>> 15 minutes or so, even though I can connect just fine earlier

Which usually means an issue between the OpenVMS VAX box and the
emulator and the rest of the Internet and your local connection.
Check the keepalive. If not enabled, enable it.

>>> If I shut down simh and restart, I can connect externally for a short
>>> time again

Which means it's not the PAKs, not the general OpenVMS VAX or simh
network configuration or related bits, and either a failure after
running for a while — check the telnet daemin logs on OpenVMS, use
AUTHORIZE to see where the default directory for the telnet daemon /
telnet server directory is located, go look for and read log files
there — or a problem with security appliances or other widgets or
connectivity between the telnet client and the telnet server. The
default directory for the telnet daemon on OpenVMS can vary, but it's
often SYS$SYSDEVICE:[TCPIP$TELNET] and the commands to view the users
from a privileged username are:

$ SET PROCESS /PRIV=ALL ! all is more than needed, but...
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> SHOW TCPIP* /BRIEF
UAF> ^Z

Etc,

The telnet client keepalive setting varies by telnet client.

>> You might want to mention a few more details...

>> ...

>
> the following are the openvms commands you asked about:

Yes, and a bunch of stuff that I did not ask about. The simh device
configuration is not related to networking, at least not once you have
a connection established such as is the case here with telnet, for
instance.

> $ UCX SHOW VERSION
>
> Compaq TCP/IP Services for OpenVMS VAX Version V5.1
> on a VAXserver 3900 Series running OpenVMS V7.3
> $ SHOW SYSTEM /NOPROC
> OpenVMS V7.3 on node AEVAX 21-AUG-2016 19:20:01.58 Uptime 0 03:29:29
> $ SHOW INTRUSION
> %SHOW-F-NOINTRUDERS, no intrusion records match specification

So fairly typical config, and nobody is poking at the telnet daemon.

I'll assume whatever is the current simh, acquired from and built from
github simh project. But again, since this all mostly works, it's
probably the keepalive.

> openvms tcpip configuration *is* dhcp, because i have no clue what the
> proper settings are for "routing" and "bind"

DHCP not an approach I'd rely on, on OpenVMS, or on any server-oriented
operating system. DHCP is for clients. Some servers might or do work
with DHCP, but more than a few — including OpenVMS — do not.

Dynamic Routing depends on what AWS networking requires. Of GATED and
ROUTED, you'll probably want GATED, though it's been a very long time
since I've used something as old as TCP/IP Services V5.1. Based on
some of the other bits posted, it looks like GATED is selected and it
certainly appears that it is working.

These are not factors here, as you have a telnet connection, and it's dropping.

> i know that the eth1 external ip is 1.1.1.1 (obviously ive blanked it out)

You are aware that 1.1.1.1 is a real IP address in a real IP block
these days, and that there are IP blocks reserved for this purpose?
Many folks will use the private blocks for this, but... "From RFC 5737:
The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and
203.0.113.0/24 (TEST-NET-3) are provided for use in documentation."

> i know that the eth1 internal ip is 172.31.106.69

Private class C behind NAT. Fairly typical and expected config.
Given that telnet connections are getting established, the
configuration is mostly working and IP routing and the rest are working.

> just for information sake, here is 'SHOW ROUTE' from openvms
>
> TCPIP> show route

> ...

> does any of this help you help me? :)

No, unfortunately the added details did not help. One of the things I
did ask about was the keepalive, and that seems to have been omitted
from the reply. Check the keepalive setting in your telnet client.
If you don't know how to check the keepalive, identify the client
involved and ask. When connections drop like this, the disconnection
can be somethiing in the intervening network connection path that's
timing out the connection, and dropping. Setting a keepalive can
suppress those timeouts. I don't know what client you're using, but
most (all?) have keepalive settings.

The other approach is to try this configuration locally, and see if
this is something weird out in AWS and AWS networking.

[Captain Harlock]

>> SHOW TCPIP* /BRIEF

It was DHCP. I switched openvms TCP/IP to static config, and I haven't had
a problem with that since.

Thanks for your help!

[steve...@verizon.net]

There was a bug in tndriver where the UCB value would not grow higher then 65536. This bug was revealed when the OS folks made the width of the UCB 32 bits. What does "show device TN" reveal?