[Simh] OpenVMS 7.2 VAX telnet failure

[Lorenzo]

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 <Mark at 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-bounces at trailing-edge.com [mailto:
> simh-bounces at trailing-edge.com] *On Behalf Of *Lorenzo
> *Sent:* Wednesday, April 30, 2014 8:30 AM
> *To:* Mark Pizzolato - Info Comm
> *Cc:* simh at 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 <Mark at 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 the details and offer
> analysis.
>
>
>
> *From:* simh-bounces at trailing-edge.com [mailto:
> simh-bounces at trailing-edge.com] *On Behalf Of *Lorenzo
> *Sent:* Wednesday, April 30, 2014 7:25 AM
> *To:* Rick Murphy
> *Cc:* simh at trailing-edge.com
> *Subject:* Re: [Simh] OpenVMS 7.2 VAX telnet failure
>
>
>
> What nmap is reporting should be the traffic from the VAX to the client.
> No matter the client I use (e.g. telnet.exe, PuTTY...), all I get is an
> endless stream of chars, which matches what appears in the traffic dump.
>
> Upgrading to SIMH 4.0 beta had no effect - after 14 hours I experienced
> the same exact problem.
>
> During the telnet outage, which happened after ~14 hours of SIMH running,
> FTP was still working fine.
>
>
>
> 2014-04-30 2:50 GMT+02:00 Rick Murphy <rick at rickmurphy.net>:
>
> At 06:21 PM 4/29/2014, Lorenzo wrote:
>
> Hi!
> I'm running OpenVMS 7.2 VAX on a simh emulator, latest release
>
> (V3.9-0 from <http://simh.trailing-edge.com>simh.trailing-edge.com) and
> compiled with networking (libpcap, no vde).
>
>
> The emulator has got its own network card to which it's attached.
> The host operating system is Linux, kernel 3.11.
> My issue is that after an apparently random amount of time (usually a few
> hours) the telnet server stops working.
> I can't get any client to log in remotely - as soon as I connect to the
> OpenVMS machine,
> all I get is a blank character sequence, as follows (dumped by nmap):
>
> SF:NULL,1138,"\xff\xfb\x01\xff\xfb\x03\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0
>
>
>
> There's a beginning of some TELNET options negotiation going on there.
>
> That's the following:
> 255 (IAC)
> 251 (WILL)
> 1   (ECHO)
> 255 (IAC)
> 251 (WILL)
> 3   (SGA) [Suppress go-ahead)
>
> That's pretty standard.
> The series of 0xff (IACs) and nulls that follow aren't.
>
> You really need to capture the traffic to-and-from. Is this coming from
> the VAX to your client, or vice versa?
>         -Rick
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140430/e9aecd7a/attachment-0002.html>