There are additional diagnostic codes available with telnet. SSH can also produce more diagnostic with -v or -vv. But with both of them disconnecting, the VPN config is looking pretty good as a culprit. Most VPN clients have the ability to enable tracing / logging. Even the Cisco client that downloads, has a settings config.
Rob Schramm On Mon, May 9, 2016, 7:41 AM Robin Atwood <[email protected]> wrote: > Is the ServerAlive parameter set in the SSH server or PuTTY? It should be > > 0, otherwise you get inactivity timeouts. > > Robin > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Sean Gleann > Sent: 09 May 2016 17:07 > To: [email protected] > Subject: Connectivity problem... > > A wide-open subject line, but networking is not my strong point, > unfortunately. > > I'm looking for some help regarding an intermittent communication failure > on our z/OS 1.13 system. > > We use PuTTY to create a tunnelled connection to TN3270, and PCOMM to > provide the 3270 emulation. > When using, say, TSO, on the PCOMM panel, everything appears to be going > well, until it simply... dies. > I get to the point of hitting ENTER or PFnn for whatever reason, and I am > presented with a the 'X clock' symbols in the status area, followed by a > disconnect some short while (< 1 minute) later. > > At the time of that disconnect, the PuTTY connection fails also (which > would be the reason for the PCOMM failure). PuTTY throws up a message box > saying "Network error: Software caused connection abort" which means > precisely nothing to me. > From there, it is possible to use PuTTY's 'Restart Session' option, and > then PCOMM's 'Connect' option to get things moving again, until the time of > the next failure. > > There's nothing showing up on the SYSLOG, and I can't think of anywhere > else I might look for more/better info. > There doesn't seem to be any pattern to the failure events in terms of > time-of-day or system loading. It just ... stops. > > For what it's worth, z/OS system is hosted by the Dallas Innovation > Center, and we've recently tried to put the system on a VPN - which is when > all this trouble started. > I'm trying to get SNMP working in the hope that I can get more info, but > *that* is probably going to be the subject of an upcoming thread... > > Can anyone point me in the direction of further diagnostics at all, please? > Any help would be much appreciated. > > Sean > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Rob Schramm The Art of Mainframe, Inc ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
