Skip to main content

Troubleshooting a Telnet Connection


TCP is the network protocol and telnet the IP protocol used by Anzio Lite and AnzioWin to connect to another host computer.

You should know the following information about your PC and your network before proceeding:

PC's IP Address

This is a unique IP address not in use by
any other machine on the network. Format
is 111.222.333.444. It is possible that these
are dynamically assigned by another server
running DHCP or something similar.

Default SubNet Mask

This is your networks subnet mask in the
format of

Default DNS

The host (not the PC's) IP address and
your networks domain name if applicable

Default Gateway

This will be the networks gateway IP
address, usually a router or switch device,
if applicable.

If you are getting a "winsock error", check your configuration settings for the above information in the network control panel items. Also see our support support document at our web site on Winsock Errors in Anzio for more information.

In Windows XP or later, you can find out this information by running “ipconfig” from a Command prompt, or through other Windows utilities.


Steps To Follow

There are some general procedures that are helpful to follow when trying to troubleshoot a TCP/IP telnet connection. These are not set in concrete, but will usually aid you in knowing where the problem lies.


Ping is a text-based utility that is included with most implementations of TCP/IP. On Windows, ping is ran from the MS-DOS Prompt. Using ping, you can determine quite a bit about your network, including whether the PC is working properly, whether you have a proper DNS and gateway, whether a particular host is up and whether TCP/IP is configured correctly for your PC.
Some common approaches to testing your TCP/IP connection involves using ping to search for the various hosts on your network. At the DOS prompt, type the following:


This will ping your local PC. If TCP/IP is not installed, this will return an error.

ping localhost

This pings your local PC by name of "localhost". If this returns an error, it is a good indication that your TCP/IP is misconfigured or not installed.


This will test for the presence of your gateway, if applicable. If you receive an error check the TCP/IP configuration, or you may have the wrong gateway for your subnet.


This will ping the host you are trying to reach by IP address. If this returns an error, check out the TCP/IP configuration.


This will ping the host you are trying to reach by name. If this returns an error, check out the TCP/IP configuration. Also, you may have a problem with your Domain Name Server (DNS).


This will test to see that your DNS host is found on the network. It may be found, but DNS may have a problem still.

Ping is also found on your host system as well. If you can telnet to one local host, but not another, you may try ping at the host to see if they can talk to each other. Then from the host, try pinging the PC.

Watching the latency between packets is a good indication of network problems. If you jump drastically up in time, it may be an indication that a telnet client will also have problems (possibly timeout issues).

PING ( from : 56(84) bytes of data.
Warning: time of day goes back, taking countermeasures.
64 bytes from icmp_seq=0 ttl=255 time=29.978 msec
64 bytes from icmp_seq=1 ttl=255 time=1.370 msec
64 bytes from icmp_seq=2 ttl=255 time=1.365 msec
64 bytes from icmp_seq=3 ttl=255 time=1.367 msec
64 bytes from icmp_seq=4 ttl=255 time=1.369 msec
--- ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/mdev = 1.365/7.089/29.978/11.444 ms

Tracert (Windows) and traceroute (UNIX) are utilities that walk through the process of reaching a host system. By running tracert/traceroute you can see the number of device hops that a packet takes to get to a particular host.

This is handy if a network device will only allow so many hops to take place from one host to another, or you are trying to locate a problem on a specific device.  By watching the trace, you can see the address of each device a packet will need to go through. From this you can determine a "down" device or a problem with a gateway address.

Also, the number of hops may be a good indication of why your access is so slow to a particular host. Look at the time frames between hops.

Tracing route to []
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms []
2 6 ms 7 ms 6 ms []
3 9 ms 9 ms 9 ms []
4 15 ms 14 ms 10 ms []
5 15 ms 13 ms 16 ms
6 17 ms 21 ms 18 ms
Trace complete.

This is another utility that normally exists on the UNIX host and on Windows. Netstat shows current statistics for your TCP/IP connection. On the PC at a MS DOS Prompt, enter  netstat -a   for general information on network connections made, and    netstat -s | more     for statistical information, including error counts, on the TCP/IP connection. Also a   netstat -?  will usually provide help for netstat.
Like ping and traceroute, netstat also exists on most host systems.  Much more information is provided on the host than the PC, but not always in a very readable format.

netstat -e
Interface Statistics
Received Sent
Bytes 771246720 136808019
Unicast packets 1006285 557114
Non-unicast packets 92884 6557
Discards 0 0
Errors 0 0
Unknown protocols 52883
netstat -s | more
IPv4 Statistics
Packets Received = 1072981
Received Header Errors = 0
Received Address Errors = 402
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 0
Received Packets Delivered = 887607
Output Requests = 556582
Routing Discards = 0
Discarded Output Packets = 0
Output Packet No Route = 0
Reassembly Required = 357642
Reassembly Successful = 172632
Reassembly Failures = 51
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0

In the last example above, you can glance over the errors. This is a good place to check into the health of your network connection. 

Timeout Problems

Telnet is a session oriented protocol, unlike ftp and web access (http) which means that the connection needs to remain open during the entire session.

Many firewalls, and almost any router doing Network Address Translation (NAT, also known as IP masquerading), will forget about a connection through them if the connection does nothing for too long. This will cause the connection to be dropped when it tries to resume.

Since AnzioWin and Anzio Lite do not have any kind of timeout built in, we are totally dependent on Windows keeping the session open. Normally Anzio will close down without any notice (depending on the Reconnect option). Windows TCP/IP does not actually have any timeout either. It does have some variables pertaining to "keep alive" and "time to live", but these are related to the protocol.

If you are getting a timeout after sitting idle for so-many minutes (Anzio closes down), the problem may be your login script on the host (check for TOUT or TMOUT), or some device in between, i.e. a bridge, router, firewall or switch. Sometimes you can set up a "ping" to run continuously in the background from PC to host or host to PC, and see if you suddenly get large latencies between pings (this would indicate a network traffic or network device problem).

If you are working and Anzio suddenly closes, this indicates a network disconnect or error has occurred. Check out your devices and your host to make sure it is not causing the problem. As an example, some DHCP servers reset after so long, and some routers/switches can reset tables at inappropriate times. Again, sometimes a traceroute or ping will show these problems.

Within AnzioWin and Anzio Lite version 12.5 and later we have added a new hexpatch option for Keep Alive that may help with this problem. We can send a NOP packet to the host every so often. To set the telnet NOP tickler to 5 seconds, do

f                                                (to get to the Function line)
HEXPATCH 18c2 05
In AnzioWin and Anzio Lite version 12.6 or later, this item can be set from the menu items under the Communicate:Network:Stay Alive option. Here you can enter the seconds between each send of a keep alive packet.

Again, this may be hiding another potential network problem however.

Optional Registry Setting

While the registry contains several TCP/IP "tuning" values, there is one option that directly influences timings.

On Windows 95, 98 or ME, the registry key  is


(it must be of type DWORD in Win95 or string in Win98/ME).
On Windows NT, 2000 and XP, the registry key is


and it must be of type DWORD.

Try setting the key's value to something like 10. This will cause Windows to try longer to keep connections alive instead of abandoning them immediately.

Optional MTU on routers

It has also been reported by several ISP that the MTU (Message Transmission Unit) size does have some bearing on whether packets get delayed in transmission across their networks. As an example, Bell South noted that if the MTU of the router connecting to their site has an MTU value of more than 1490 there could be problems and long latency in packets crossing their network. They recommend setting the MTU value at 1400.

Winsock Errors

Winsock errors are usually numeric in nature and cover a very wide variety of problems. You can find a complete list of the winsock errors and what they refer to in a book called "Windows' Sockets Network Programming" by Quinn Shute. They are listed in numeric order at Sockets.Com and Microsoft has a complete list (though it is spread over several support pages. See our support document Winsock Errors in Anzio for more information.

The most common problems that are associated with a Winsock Error are a) the PC's TCP/IP is not configured correctly, b) there is a network or cable problem, c) the host on the other end is experiencing a problem, or d) you experienced a network problem such as a bad host name or bad IP address.

Check all your network configuration settings, and check with the system administrator on the other end. Also see if you can establish a connection with some other host, elsewhere on the network. Also use the Ping command (described below) to see if you can get a response from some host.

Dial-up TCP/IP Problems

What we covered above applies to both direct (local area network) connections and dial-up networking (wide area network) connections.

One of the common problems we run into is a PC that has support for two TCP/IP connections, one for the Dial-Up adapter and one for the local area network.

When you start up Anzio Lite or AnzioWin, the software will try to establish a connection to the host. Many times when you load a web browser or other Internet software, your PC is set to use a default dial-up connection for network access. When Anzio comes up, it then also does the Dialer, even if you are trying to connect locally.

This situation is correctable by changing the default connection type for TCP/IP. In many implementations of Windows, there is an Internet icon on the Control Panel. Double-click on this item and go to the Connections tab (these options are global, not just for your browser) and change the default connection type to be over a local area network.

If this icon does not exist in your Control Panel (you have not updated the Dial-up software for Windows), then you may have to go through the following procedure:

  1. Go to the Control Panel : Network icon.
  2. Write down the Properties for the TCP/IP -> Dialup Adapter and then Remove it.
  3. Make sure Anzio works as you wish and does not call up the dialer.
  4. Add Microsoft TCP/IP and "bind" it to the dialup adapter again.

The above procedure should only be followed if you are familiar with the Network Control Panel item and its behavior. What this will do is change the order of the two TCP/IP's in the registry file. While not guaranteed to work, it usually does.


If you have all the necessary information on your network, you can usually set up TCP/IP for Windows easily. However, if problems do occur, you should contact your network administrator for help.

Copyright © 2024 Rasmussen Software, Inc. Legal Information & Privacy Policy
Send comments and suggestions to