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 <[email protected]>: > 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:* [email protected] [mailto: > [email protected]] *On Behalf Of *Lorenzo > *Sent:* Wednesday, April 30, 2014 8:30 AM > *To:* Mark Pizzolato - Info Comm > *Cc:* [email protected]; 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 <[email protected]>: > > 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:* [email protected] [mailto: > [email protected]] *On Behalf Of *Lorenzo > *Sent:* Wednesday, April 30, 2014 7:25 AM > *To:* Rick Murphy > *Cc:* [email protected] > *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 <[email protected]>: > > 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 > > > > >
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
