Extra! X-treme 9.5 and higher
InfoConnect Desktop (including Pro, or for Unisys) 16.0 and higher
Reflection Desktop (including Pro, for X, for IBM, or for UNIX and OpenVMS) 16.0 and higher
Rumba Desktop 10.0 and higher
How to troubleshoot host connection drops with Microsoft Windows-based Micro Focus emulation software when connected over a Virtual Private Network (VPN). When a host connection (3270, 5350, VT) is made to a corporate network over a VPN, in a typical Work-from-Home (WFH) scenario, there is the possibility of unexpected host connection drops, and this technical article produces some suggestions on how to troubleshoot these issues.
When connected from locations other than those located directly on a corporate network, users will sometimes report a problem where their host session appeared to be getting disconnected. This technical article contains some observations and ideas on how to troubleshoot these types of issues, using the Reflection Desktop software as an example, but these same techniques can be used with other Micro Focus software. When working from home, some user's internet connections or VPN software may not function as reliably as their corporate networks. Thus, there is the potential for problems to occur, with dropped connections being one type of issue.
Although Reflection Desktop (and all the other thick-client programs like Extra!, InfoConnect, and Rumba) use TCP/IP connections to get to the host, these are considered "persistent" TCP/IP connections, unlike the connections used by web browsers using HTTP and HTTPS (which are quickly opened, established, used and then closed; over-and-over again). These Windows-based host emulators build a TCP/IP connection using a pair of TCP Ports, one on the PC side and one at the host side, and the TCP/IP connection between these pairs must be maintained the whole time the host session is connected or else the host session will drop and disconnect. Once the TCP connection is established, it is maintained by Microsoft Windows (as persistent), until one of the parties at either end (typically the Host or PC software), decides to intentionally terminate the connection.
Reflection Desktop does not talk directly to the TCP/IP stack of Microsoft Windows, but instead talks though the Windows Socket Interface (WinSock), which in turn then talks to the Windows TCP/IP stack. Thus, when you take a Reflection communication trace, or get log files from the Reflection software, you are getting information âaboveâ the WINSOCK interface, and not from the TCP/IP stack or the Host directly. If a SocketClose() type command is seen in the Reflection communication trace, it could mean a number of things; from the Host sending a disconnect, something on the network dropping the TCP connection, or the Windows TCP/IP stack itself just closing the connection. All these events will cause the WINSOCK interface to report back to Reflection that the Host connection is gone, but will not give the real detailed reason as to why.
Although software communication traces and log files can be helpful, typically you will have to resort to a network level trace (like Wireshark) on the PC to see what is happening, even if the connection is encrypted. Start by looking for the TCP ports in use by the client for the TCP/IP connection (by examining the Telnet negotiation) and then follow this set of PC and host TCP ports to the disconnect event (TCP FIN or RST). Even if you canât read the traffic in the packets because of encryption, you can examine the TCP Requests and Responses (ACKs) to make sure they match up, to determine if traffic is making it from the PC side to the Host side of the connection and back.
Some Wireshark traces recently examined have shown the Windows TCP/IP stack on the PC sending SNA data to the host but the PC never receiving a TCP/IP Acknowledgement packet back. This is an indication that the data never arrived at the Host end, or else the data arrived and the response did not have a path back to the workstation. Regardless, the Wireshark trace showed the PC waited a few hundred milliseconds and then it started to send TCP/IP re-transmissions to the Host. These packets were never acknowledged, and the time interval between re-transmissions was increased until after about 5 retries over 6 seconds or so, the TCP/IP stack on the PC terminated the connection (due to lack of response). Reflection eventually received a SocketClose() type of message from WIINSOCK interface, and a dialog appeared in the Reflection host session that the host connection was dropped. To the user it appeared that Reflection dropped the connection, since they had pressed the ENTER key and sent a request to the Host and never got data back and a failed connection message.
Examining the Wireshark trace in more detail revealed that no other TCP/IP port pair dropped at this time, indicating that the connection to the Internet Service Provider (ISP) was still up and available. The Wireshark trace was taken using a Remote Desktop to the client, and the Remote Desktop connection also did not drop at this time either. So the connection from the userâs home PC via the ISP seemed fine, it sure looked like it might be possible that the VPN software or the host could be the culprit at dropping this particular connection. In this scenario, just getting logs and traces from the Reflection software will be inconclusive, as it was really important to see what is happening on the wire (via Wireshark) at the network layer, to get solid data to make a definitive conclusion. This information confirmed that the Reflection software was not the party which caused the dropped host link and the next step would be to get a Wireshark trace at the other end of the VPN (host end), for without it, it would be impossible to know who and why the connection dropped and which party initiated the dropped link.