From lore.cfr at gmail.com Tue Apr 29 18:21:09 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Wed, 30 Apr 2014 00:21:09 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure Message-ID: Hi! I'm running OpenVMS 7.2 VAX on a simh emulator, latest release (V3.9-0 from 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 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\x SF:ff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\ SF:xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0")%r(G SF:enericLines,16D8,"\xff\xfb\x01\xff\xfb\x03\xff\xff\xff\xff\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\x SF:ff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x SF:ff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\ SF:xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0"); I've tried the latest OpenVMS TCP/IP patch but with no luck: TRISTE::SYSTEM$ tcpip TCPIP> show ver Compaq TCP/IP Services for OpenVMS VAX Version V5.1 - ECO 1 on a VAXserver 3900 Series running OpenVMS V7.2 TRISTE::SYSTEM$ product show history ----------------------------------- ----------- ----------- -------------------- PRODUCT KIT TYPE OPERATION DATE AND TIME ----------------------------------- ----------- ----------- -------------------- DEC VAXVMS VMS72_PCSI V1.1 Patch Install 29-APR-2014 05:48:44 DEC VAXVMS TCPIP_ECO V5.1-151 Patch Install 29-APR-2014 05:00:13 DEC VAXVMS VMS72_PCSI V1.1 Patch Install 29-APR-2014 04:58:21 DEC VAXVMS TCPIP V5.1-15 Full LP Install 26-APR-2014 14:18:25 DEC VAXVMS TCPIP V5.0-9 Full LP Remove 26-APR-2014 14:01:59 DEC VAXVMS TCPIP V5.0-9 Full LP Install 26-APR-2014 13:48:42 DEC VAXVMS DECNET_PHASE_IV V7.2 Full LP Install 26-APR-2014 13:27:13 DEC VAXVMS VMS V7.2 Transition Reg Product 26-APR-2014 13:27:00 ----------------------------------- ----------- ----------- -------------------- 8 items found Restarting the TCP/IP stack doesn't help. Other services running on it (e.g. FTP server) are not affected. Bringing the interface down and up again on the host machine doesn't help either. Here's my vax.ini: ; ; Load CPU microcode load -r /usr/local/vax/data/ka655x.bin ; ; Attach non-volatile RAM to a file attach nvr /usr/local/vax/data/nvram.bin ; ; This virtual machine has 64M memory set cpu 64m ; ; idle value set cpu idle=VMS ; ; Define disk drive types. RA92 is largest-supported VAX drive. set rq0 ra92 set rq1 ra92 set rq2 ra92 set rq3 cdrom ; ; Attach defined drives to local files attach rq0 /usr/local/vax/data/d0.dsk attach rq1 /usr/local/vax/data/d1.dsk attach rq2 /usr/local/vax/data/d2.dsk ; ; Attach the CD-ROM to its file (read-only) attach -r rq3 /usr/local/vax/data/openvms72.iso ; ; Disable unused devices. It's also possible to disable individual devices, ; using a construction like "set rq2 disable" if desired. ; set rl disable set ts disable ; ; Attach Ethernet to a network interface set xq mac=00-21-85-00-b7-a7 attach xq eth0 ; ; Now start the emulator boot cpu Any thoughts? Thanks for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: From lore.cfr at gmail.com Wed Apr 30 10:24:57 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Wed, 30 Apr 2014 16:24:57 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <201404300050.s3U0oElE024244@rickmurphy.net> References: <201404300050.s3U0oElE024244@rickmurphy.net> Message-ID: 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 : > 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 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: From Mark at infocomm.com Wed Apr 30 10:59:34 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 30 Apr 2014 07:59:34 -0700 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: References: <201404300050.s3U0oElE024244@rickmurphy.net> Message-ID: <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.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 >: 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 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: From lore.cfr at gmail.com Wed Apr 30 11:30:03 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Wed, 30 Apr 2014 17:30:03 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> Message-ID: 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 : > 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 : > > 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 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: From Mark at infocomm.com Wed Apr 30 11:45:28 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 30 Apr 2014 08:45:28 -0700 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.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 >: 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 >: 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 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: From lore.cfr at gmail.com Wed Apr 30 17:51:30 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Wed, 30 Apr 2014 23:51:30 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> Message-ID: 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 : > 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 : > > 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 : > > 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 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: From goathunter at goatley.com Wed Apr 30 18:22:50 2014 From: goathunter at goatley.com (Hunter Goatley) Date: Wed, 30 Apr 2014 17:22:50 -0500 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> Message-ID: <536177BA.2020809@goatley.com> On 04/30/2014 10:45 AM, Mark Pizzolato - Info Comm wrote: > > 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. > Yes, that is true. -- Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ goathunter at goatley.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Wed Apr 30 20:58:17 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 30 Apr 2014 17:58:17 -0700 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A27D11AA@REDROOF2.alohasunset.com> 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-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Lorenzo Sent: Wednesday, April 30, 2014 2:52 PM To: Mark Pizzolato - Info Comm Cc: simh at 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 >: 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 >: 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 >: 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 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: From lore.cfr at gmail.com Tue Apr 29 18:21:09 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Wed, 30 Apr 2014 00:21:09 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure Message-ID: Hi! I'm running OpenVMS 7.2 VAX on a simh emulator, latest release (V3.9-0 from 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 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\x SF:ff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\ SF:xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0")%r(G SF:enericLines,16D8,"\xff\xfb\x01\xff\xfb\x03\xff\xff\xff\xff\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\x SF:ff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x SF:ff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\xff\ SF:xff\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 SF:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ SF:0"); I've tried the latest OpenVMS TCP/IP patch but with no luck: TRISTE::SYSTEM$ tcpip TCPIP> show ver Compaq TCP/IP Services for OpenVMS VAX Version V5.1 - ECO 1 on a VAXserver 3900 Series running OpenVMS V7.2 TRISTE::SYSTEM$ product show history ----------------------------------- ----------- ----------- -------------------- PRODUCT KIT TYPE OPERATION DATE AND TIME ----------------------------------- ----------- ----------- -------------------- DEC VAXVMS VMS72_PCSI V1.1 Patch Install 29-APR-2014 05:48:44 DEC VAXVMS TCPIP_ECO V5.1-151 Patch Install 29-APR-2014 05:00:13 DEC VAXVMS VMS72_PCSI V1.1 Patch Install 29-APR-2014 04:58:21 DEC VAXVMS TCPIP V5.1-15 Full LP Install 26-APR-2014 14:18:25 DEC VAXVMS TCPIP V5.0-9 Full LP Remove 26-APR-2014 14:01:59 DEC VAXVMS TCPIP V5.0-9 Full LP Install 26-APR-2014 13:48:42 DEC VAXVMS DECNET_PHASE_IV V7.2 Full LP Install 26-APR-2014 13:27:13 DEC VAXVMS VMS V7.2 Transition Reg Product 26-APR-2014 13:27:00 ----------------------------------- ----------- ----------- -------------------- 8 items found Restarting the TCP/IP stack doesn't help. Other services running on it (e.g. FTP server) are not affected. Bringing the interface down and up again on the host machine doesn't help either. Here's my vax.ini: ; ; Load CPU microcode load -r /usr/local/vax/data/ka655x.bin ; ; Attach non-volatile RAM to a file attach nvr /usr/local/vax/data/nvram.bin ; ; This virtual machine has 64M memory set cpu 64m ; ; idle value set cpu idle=VMS ; ; Define disk drive types. RA92 is largest-supported VAX drive. set rq0 ra92 set rq1 ra92 set rq2 ra92 set rq3 cdrom ; ; Attach defined drives to local files attach rq0 /usr/local/vax/data/d0.dsk attach rq1 /usr/local/vax/data/d1.dsk attach rq2 /usr/local/vax/data/d2.dsk ; ; Attach the CD-ROM to its file (read-only) attach -r rq3 /usr/local/vax/data/openvms72.iso ; ; Disable unused devices. It's also possible to disable individual devices, ; using a construction like "set rq2 disable" if desired. ; set rl disable set ts disable ; ; Attach Ethernet to a network interface set xq mac=00-21-85-00-b7-a7 attach xq eth0 ; ; Now start the emulator boot cpu Any thoughts? Thanks for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: From lore.cfr at gmail.com Wed Apr 30 10:24:57 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Wed, 30 Apr 2014 16:24:57 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <201404300050.s3U0oElE024244@rickmurphy.net> References: <201404300050.s3U0oElE024244@rickmurphy.net> Message-ID: 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 : > 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 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: From Mark at infocomm.com Wed Apr 30 10:59:34 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 30 Apr 2014 07:59:34 -0700 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: References: <201404300050.s3U0oElE024244@rickmurphy.net> Message-ID: <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.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 >: 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 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: From lore.cfr at gmail.com Wed Apr 30 11:30:03 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Wed, 30 Apr 2014 17:30:03 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> Message-ID: 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 : > 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 : > > 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 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: From Mark at infocomm.com Wed Apr 30 11:45:28 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 30 Apr 2014 08:45:28 -0700 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.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 >: 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 >: 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 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: From lore.cfr at gmail.com Wed Apr 30 17:51:30 2014 From: lore.cfr at gmail.com (Lorenzo) Date: Wed, 30 Apr 2014 23:51:30 +0200 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> Message-ID: 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 : > 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 : > > 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 : > > 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 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: From goathunter at goatley.com Wed Apr 30 18:22:50 2014 From: goathunter at goatley.com (Hunter Goatley) Date: Wed, 30 Apr 2014 17:22:50 -0500 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> Message-ID: <536177BA.2020809@goatley.com> On 04/30/2014 10:45 AM, Mark Pizzolato - Info Comm wrote: > > 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. > Yes, that is true. -- Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ goathunter at goatley.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Wed Apr 30 20:58:17 2014 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 30 Apr 2014 17:58:17 -0700 Subject: [Simh] OpenVMS 7.2 VAX telnet failure In-Reply-To: References: <201404300050.s3U0oElE024244@rickmurphy.net> <507BEC50238C2442A55CE81420C9F144A27D11A3@REDROOF2.alohasunset.com> <507BEC50238C2442A55CE81420C9F144A27D11A4@REDROOF2.alohasunset.com> Message-ID: <507BEC50238C2442A55CE81420C9F144A27D11AA@REDROOF2.alohasunset.com> 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-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Lorenzo Sent: Wednesday, April 30, 2014 2:52 PM To: Mark Pizzolato - Info Comm Cc: simh at 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 >: 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 >: 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 >: 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 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: