1)

2)

3)

4)

5)

1)

Symptom:

An error message appears when you connect that says Winsock or some of its components are missing.

Possible Cause 1:

TCP/IP software is prehistoric, proprietary, or not installed.

Ways to test:

DynaComm accesses TCP/IP through the standard Winsock 1.1 API supported by most vendors since Windows has been around. Most new systems have it installed already as part of Win 95 or NT, but it is possible to remove it. Search the harddrive and where Windows is installed for WINSOCK.DLL, the interface file that will be part of the TCP/IP software.

Possible Cause 2:

TCP/IP software failed to load.

Ways to test:

In Win 3.x environments, DOS versions of TCP/IP from several vendors are still in common use. These require lines in the AUTOEXEC.BAT file to run TCP/IP when you boot the system so these connectivity services can be used from Windows. In Win 95/NT, the TCP/IP protocol must be installed on the system and bound to a network adapter. Verify this in Network Properties of the workstation. You can use the PING utility that comes with most TCP/IP packages to verify it is installed properly. In Win 95 or NT, go to a Command Prompt and type ping hostname to use the ping utility. If it gives a response time, TCP/IP is probably installed correctly on the system.

2)

Symptom:

Cannot connect to host, host unreachable, or host unknown

Possible Cause 1:

You are not on the network due to network card, cable, or access problems.

Try to access a network resource.

Possible Cause 2:

You are on the network, but TCP/IP is not working properly.

Ways to test:

Use a PING utility to the loopback address to test TCP/IP connectivity software is installed properly and bound to the network card. In Win 95 or NT, you can go to a DOS Command prompt and type PING 127.0.0.1 to send a test packet to the network card. If this does not work, TCP/IP is not installed properly. If this does work, ping a different host system on the network to see if you can send TCP/IP packets across the network.

Better yet, use TELNET.EXE, the applet that comes with Win 95 and NT to make a telnet connection to an available host. (It is rare that Ping works and Telnet fails, but it can happen). If your system is running multiple connectivity protocols, network clients, and/or network adapters, there is a increased risk that TCP/IP does not work due to other installed components. Check on the latest connectivity driver patches from the vendors to address issues such as those. Since DynaComm products access that standard Winsock API, getting TCP/IP working such that you can connect with TELNET.EXE is sufficient to work with DynaComm. (For exceptions, read next symptom section).

Possible Cause 3:

Gateway is down, or host is down. You are on your network, can connect to other systems, can't get to the host from your network.

Ways to test:

If you know the IP address of the gateway or bridge, you can Ping it to see if it is alive and accessible across the network. Check with other users or the host administrator to see if the host is up.

Possible Cause 4:

The hostname isn't resolved to a usable IP address, or isn't entered.

Ways to test:

Verify that the host address is entered in the session file. If it is, use the IP address instead of a host name for the host address in DynaComm. If it connects fine using the IP address, your system isn't set up to use the correct DNS (domain name server) to resolve the host name into the IP address, the DNS is down, or the host name you specify doesn't match any of its entries (typo). If a different workstation is not exhibiting the connection problem, you can go to that workstation to compare DNS addresses, which are set in the TCP/IP protocol in Network Properties. Try PINGing the DNS system to verify you can access it across the network.

Possible Cause 5:

Your connection request is being blocked or rejected by the host or a firewall.

Ways to test:

Verify that the correct emulation is being used, and disable Terminal Type Negotiation in the Telnet connector properties as some hosts will refuse connection requests by unknown terminals. Try to ping the host address, as described above. Firewalls are often based on the IP address of the workstation. Check with the host administrator to check about getting beyond a firewall.

Possible Cause 6:

The telnet port specified is incorrect.

Ways to test:

The default port for telnet connections is 23, but this can be configured on the host per host application. This value, like the host address, has to be known to make a connection. Check a working installation for this value, or check with the host application administrator.

Possible Cause 7:

The network is slow so the connection request times out.

Ways to test:

The host and client may each or both incorporate a connection timeout. The client side TCP/IP software may also incorporate a default timeout value. If the connection isn't established in that period, it will fail to connect. If the problem is network slowness, response might be slower than usual when the connection succeeds. You can use a PING utility to get an idea of the time to route the packets, a decent test of network slowness but not necessarily of gateway or host load. In Win 95 or NT, go to a command prompt and type PING HostName where HostName is the IP address or telnet hostname you are using to connect to the host system. If you know the address of intermediate gateways, you can ping them too to get a feel for the bottleneck. Test at a time of less activity to see if it is more reliable, and consult a network administrator to investigate further.

3)

Symptom:

Can connect to the host system with one connectivity product, not with others.

Possible Cause 1:

The correct WINSOCK.DLL, the interface used by third party applications to access connectivity services, is found by one application but not the other.

Ways to test:

There may be more than one version of TCP/IP software on the system, but only one version running. Make sure the copy of WINSOCK.DLL that is found in the path goes with the version that is installed. Use Windows Explorer or File Manager to search the harddrive for copies of this file. If multiple copies are found, make sure only the correct one is in the path. (In Win 95, a backup copy is stored in \Windows\SYSBCKUP\ which is fine) You can address this problem by modifying the Path environment variable, or renaming the unused versions of WINSOCK.DLL to some other filename to make sure they are not loaded.

Possible Cause 2:

A proprietary version of WINSOCK.DLL was installed by one application, and only supports that product.

Ways to test:

Try using the TELNET.EXE applet that comes with Win 95 or Win NT. If it connects okay and there is only one version of WINSOCK.DLL installed, this is not the issue. Windows now includes TCP/IP and several vendors offer TCP/IP that supports 3rd party connectivity, so any of these open connectivity products will work with DynaComm.

Possible Cause 3:

Improper support for optional telnet parameters or bug.

Ways to test:

If the host is up, you can connect with comparable connectivity products, and you can connect from the workstation to other host systems, the issue may be with an improperly set telnet parameter. This may be from a user selection in the Advanced telnet parameters, or a connection parameter negotiated with this host system that is not handled properly. This sort of issue is best resolved by speaking to someone at our Helpdesk to verify appropriate settings, get patches, or make connection traces.

4)

Symptom:

Host connects sporadically, but works fine if it connects. Seems to happen with any connectivity product.

Possible Cause 1:

Host system, network, or some gateway en route is at capacity, and the connection request times out.

Ways to test:

The host and client may each or both incorporate a connection timeout. The client side TCP/IP software may also incorporate a default timeout value. If the connection isn't established in that period, it will fail to connect. If the problem is network slowness, response might be slower than usual when the connection succeeds. You can use a PING utility to get an idea of the time to route the packets, a decent test of network slowness but not necessarily of gateway or host load. In Win 95 or NT, go to a command prompt and type PING HostName where HostName is the IP address or telnet hostname you are using to connect to the host system. If you know the address of intermediate gateways, you can ping them too to get a feel for the bottleneck. Test at a time of less activity to see if it is more reliable, and consult a network administrator to investigate further.

Possible Cause 2:

The IP address of your system is a duplicate of another system on the network.

Ways to test:

TCP/IP packets may get routed to your IP address twin instead, preventing effective connection negociation from taking place. If your IP address is being used, you will usually get an error message when you boot or log onto Windows. To determine your IP address, go to a command prompt and type WINIPCFG. The IP address of your system is configured in your TCP/IP protocol so if yours is a duplicate, notify your network administrator to assign a different one.

5)

Symptom:

Connection is slow, or slow to respond to user input.

Possible Cause 1:

The network is running slow.

Ways to test:

Use the PING utility as described earlier to determine the average travel time of TCP/IP packets across the network. If the problem is isolated to a particular site or leg of the network, this may also be useful information for the network administrator.

Possible Cause 2:

Host system has heavy load.

Ways to test:

Connect to a different host system on the same network for comparison.

Possible Cause 3:

Client connectivity software configuration issue.

Ways to test:

If the problem occurs with no changes to your configuration, this is not the cause. Comparing configuration with a user not experiencing the problem is often an expedient way to identify the change that caused a problem. There are a couple of good places to check. DynaComm allows you to decrease network traffic by buffering user input momentarily and sending more data per packet. This is unused by default but is configurable with a specified idle timer, which if set inappropriately could cause this problem. That is in the Advanced section of the Telnet connector properties. Aside from this, there are emulation specific items that may cause a the terminal (connectivity software) to process user input differently to enhance responsiveness. Check the emulation configuration for suspect values.