Whoa! I've actually found a way to replicate the failure, both on 7.2 and
7.3.
Just expose the machine to the internet and wait for someone to run
some security scan on it, e.g. a command like nmap -v -A IP_ADDR
One or two nmap scans to the host are sufficient to make the telnet
service crash and to render it inaccessible.
I've discovered this after noticing that in my test setup
the only node experiencing the issue was the one publicly
available to the internet.
Here you can find a few traffic dumps, done with Wireshark:
* working telnet, successful login:
https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_ok.pcapng
* broken telnet, stream of chars:
https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail.pcapng
* broken telnet, stream of chars with some interaction attempts on my
side:
https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail_interact.pcapng
* full exchange between nmap and the OpenVMS machine:
https://enlab.net/~lorenzo/dump/2014-05/vms72_telnet_fail_nmap.pcapnghttps://www.google.com/url?q=https%3A%2F%2Fenlab.net%2F%7Elorenzo%2Fdump%2F2014-05%2Fvms72_telnet_fail_nmap.pcapngsa=Dsntz=1usg=AFQjCNE5fYAFMalm7n4H_ddXOW6SbpdkMQ
In these dumps the OpenVMS machine is always on 192.168.1.17.
This filter rule:
(ip.src==192.168.1.17 or ip.src==192.168.1.227) and
(ip.dst==192.168.1.17 or ip.dst==192.168.1.227)
has been applied to the dumps in order to clear them
from all the LAN broadcast garbage.
The last log should be the most interesting one,
as it may contain the key to find out what's going on.
I think that the telnet service is just dying under the
amount of data that nmap is sending to probe it. Memory exhaustion?
To sum it all up, after running a port scan with nmap to audit
my network from the outside... I was crashing my own OpenVMS box.
It's a tough world.
[sent to comp.os.vms too]
On Thu, May 1, 2014 at 2:58 AM, Mark Pizzolato - Info Comm
m...@infocomm.com wrote:
You can do BOTH (rule out the variables you have planned), and AT THE SAME
TIME, collect traffic with WireShark. You can start Wireshark Data
collection any time BEFORE (and through) when you start to see the
problem. So, even if you’ve already setup the next step in your plans, you
can still turn on WireShark to collect the relevant data…
*From:* simh-boun...@trailing-edge.com [mailto:
simh-boun...@trailing-edge.com] *On Behalf Of *Lorenzo
*Sent:* Wednesday, April 30, 2014 2:52 PM
*To:* Mark Pizzolato - Info Comm
*Cc:* simh@trailing-edge.com; Rick Murphy
*Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure
As I stated in comp.os.vms too, I came up with this testbed:
* OpenVMS 7.2, attached to a newer Realtek network card
* OpenVMS 7.3, fresh setup temporarily running on the integrated network
card
Albeit seeming messy, this should allow me to rule out a few more
variables in ~24 hours.
In case of failure I'm ready to dump traffic with Wireshark and post it
here.
Thanks
2014-04-30 17:45 GMT+02:00 Mark Pizzolato - Info Comm m...@infocomm.com:
Of course, you are free to try to work around the issue, but traffic
captures will explain what is really happening and then determine what the
simplest workaround might be. Traffic analysis will either point to or
eliminate the need or desire to swap cards.
I’d suggest that you try using the MultiNet IP stack. I’ve had experience
with MultiNet for 20+ years and even now, leave telnet sessions connected
for many days and never see a problem. Switching to MultiNet will avoid
the need to migrate users or configure a new OS from scratch or perform an
upgrade. I strongly suspect that both MultiNet and the HP TCP stack can be
installed on the same system at the same time as long as you only start one
OR the other in your systartup configuration.
*From:* simh-boun...@trailing-edge.com [mailto:
simh-boun...@trailing-edge.com] *On Behalf Of *Lorenzo
*Sent:* Wednesday, April 30, 2014 8:30 AM
*To:* Mark Pizzolato - Info Comm
*Cc:* simh@trailing-edge.com; Rick Murphy
*Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure
Before starting to dig into traffic captures I'd like to try two more
things:
* a OpenVMS 7.3 setup on a new SIMH machine - if that works then I can
think about migrating users and data from 7.2
* using a different ethernet card to rule out layer 1 problems
This problem is not easily reproducible, it just happens, so I can only
report back after a certain amount of time.
Thanks for now
2014-04-30 16:59 GMT+02:00 Mark Pizzolato - Info Comm m...@infocomm.com:
As Rick suggested, you should capture traffic in both directions.
Wireshark is an excellent tool for that. Additionally, Wireshark has
built-in protocol decoders which can interpret what is happening in the TCP
telnet session. If you aren’t familiar with, or don’t want to dig into the
details of the packet innards, you can save the capture contents, make it
available, and let me or someone else can interpret
