Attaching Non-TCP/IP Devices with telnet

Stefan C. Johnson

Given the ubiquitous nature of IP networks, it is not hard to imagine that one day every intelligent and semi-intelligent device will be accessible through a common network. The benefits of such interconnection are innumerable, and new applications continue to be found. One of the primary reasons for the success of IP-based networks is that most devices that one would want to attach in this way, can be; the hardware and software are readily available.

But, just because a device is not readily network attachable does not mean we have no interest in attaching it. This article is about using commonly available hardware to attach an "unattachable" device to an IP network. The techniques and equipment can be used to make virtually any serial device accessible as part of a TCP/IP network. Some applications of these techniques include automated device control and remote data logging.

Project Requirements

My initial interest in this area was sparked by a client's requirement to support users of their Hewlett Packard HP3000 computer located off-site. An initial proposal called for the installation of time-division multiplexers (TDMs) at the host and remote locations. The TDMs were to be supported by a dedicated communications link between the two locations.

The client's machine was what I'll call a "serial host." It was an HP3000 running an operating system that didn't support direct attachment to a TCP/IP network. All terminals were attached to the machine through RS-232 style interfaces.

The client had established a company-wide network that extended to all corporate locations, including the two that contained the serial host and its intended remote users. Early on, we decided to find a way to attach the serial host and its remote terminals using the IP network already in place between the two sites.

Because the link between the host and the terminal was essentially an asynchronous serial line, the problem was to find a way of providing a "serial tunnel" for the asynchronous data to pass across the IP network. The concept of tunneling is often found in discussions of multiprotocol communications. Using a tunnel involves wrapping the data encoded with one protocol (in our case asynchronous data) in another (in this case TCP/IP). At the remote location the original data is unwrapped and resumes it original form intact.

Remote Terminal Access

In this case, a telnet server provided the "wrapping" service. A telnet server is a protocol conversion device that encapsulates (or "wraps") asynchronous serial data in TCP packets. Additionally, most telnet servers are relatively intelligent devices and are able to manage session establishment and termination. Most applications of telnet servers require them to be installed between a serial terminal(s) and an IP network. The individual terminal user uses the telnet server to establish an IP-based session with a remote host using telnet protocol.

I needed the protocol conversion function provided by a telnet server to reside at the host site. Most telnet servers not only allow outgoing sessions, but incoming as well, and this feature provided the key to the design of this serial host attachment problem. By installing a telnet server between a set of ports on the serial host and the IP network, a pool of session-accepting services was created that were accessible throughout the company-wide IP network. Support for inbound telnet sessions is generally known as "reverse telnet" support, and should be specified when trying to determine whether a particular telnet server can be used in this manner.

Configuration

We used the ETS8 telnet server from Lantronix for this project. Remote configuration and installation was possible because the server supports IP address configuration using either BOOTP or RARP protocol. Both of these protocols use the MAC address of the device to be configured as a key to request an IP address from a local serving device (with BOOTP, an initial load program can be downloaded as well). Once the telnet server has self-configured its IP address, it is a simple matter to telnet into the server and complete the configuration remotely.

The next step in configuring the telnet server is to specify the communication characteristics of the serial ports. These characteristics include speed, character size, and parity and must be identical to those configured on the serial host ports. The ETS8 commands required to do this for all of its eight ports are shown below. telnet servers from other manufacturers have similar facilities.

DEFINE PORT 1-8 SPEED 9600

DEFINE PORT 1-8 CHARACTER SIZE 8

DEFINE PORT 1-8 PARITY NONE

Also, it made sense to disable the normal outgoing (or port-to-network) operation of the server on these ports since they were to be connected to a port on the serial host.

DEFINE PORT 1-8 ACCESS REMOTE

In a reverse telnet configuration, one or more ports on the ETS8 are logically associated together as a "service," and are accessible by specifying the "service name." This is performed by the following command where "hp3000" is the service name.

DEFINE SERVICE hp3000 PORTS 1-8

With this command in place, a user telneting into the telnet server need only issue a connection request to the service name to establish a session with one of the available ports associated with this service name.

To remove the requirement for the users to manually issue the connection request, the incoming telnet sessions were preconfigured to automatically attach to the service as defined above. Incoming telnet sessions are handled in the ETS8 as virtual ports. The ETS8 allows various characteristics of these virtual ports to be configured by using the normal port configuration commands with the port number specified as "0." The following commands establish a "preference" for incoming telnet sessions to automatically connect to the hp3000 service.

DEFINE PORT 0 PREFERRED SERVICE hp3000

DEFINE PORT 0 AUTOCONNECT ENABLED

Listing 1 shows the output from the LIST SERVER, LIST PORT 1 CHARACTERISTICS, LISTPORT0 CHARACTERISTICSand SHOW SERVICE CHARACTERISTICS commands.

Specialty cables were designed and manufactured for the connection between the serial host and the telnet server. The specific serial host in this project, a Hewlett Packard HP3000, physically presents its serial ports (called "ATP" ports) in the form of a 3-pin connector containing RS-232 transmit, receive, and signal ground. The ETS8 presents its RS-423 serial connections in a 6-pin RJ-style jack with separate returns for the transmit and receive ground signals. The RS-423 interface may be familiar to DEC equipment users because it is used on most LAT terminal servers. Converting RS-423 to the HP3000's RS-232 compatible ATP port is as easy as tying the two signal grounds together.

Workstation Attachment

The original proposal had called for dedicated HP terminals to be installed at each remote location. A site visit confirmed that IBM-compatible PCs were installed on the desks of each of the users that required access to the serial host. This meant that, instead of dedicated terminals, terminal emulation software could be used on each PC workstation as long as (a) an emulator could be found that matched the characteristics required by the serial host, and (b) the emulator supported an IP protocol stack. This last requirement was important to leverage the existing network connections installed on each of the PC workstations.

Note that not all terminal emulation packages are created equal. Terminal emulation software that uses one of the PC's serial ports to communicate is relatively common. Direct TCP/IP support using an installed protocol stack is not as common. In regard to the first requirement above, we found that the HP3000 required attached devices to emulate a specific terminal type, namely one of the members of the HP23xx or HP26xx terminal families.

WRQ (Walker Richer & Quinn, Inc.) makes just such a terminal emulation package, Reflection. This software is a full-functioned emulation package with support for a large number of off-the-shelf TCP/IP protocol stacks. Included with the package is a program called the Connection Manager, which handles the details of telnet session establishment and termination. Tests of the Reflection software showed that it would work well for this application.

One of the first problems found during initial user testing was with the complicated sign-on sequence needed to establish a session with the serial host. First, the terminal emulation software had to be loaded, followed by directions to the Connection Manager to establish a session with the host-based telnet server. Then, the telnet server's own sign-on requirements had to be satisfied before the "serial tunnel" was in place and direct communication with the serial host could proceed. This was just a little too much to expect of the average user on a continuing basis, so we automated the sign-on sequence using Reflection's scripting language.

The scripting capabilities of Reflection also proved to be beneficial when the client requirements were expanded and two additional telnet servers were installed to support 16 additional terminal ports. The two additional telnet servers were configured with their own individual IP addresses. With this configuration, the sign-on process needed to be modified to iteratively try each telnet server until an open port was found. Using the Reflection Command Language, this modification was relatively easy to implement (See Listing 2).

Remote Printing

Not long after the telnet servers were in place and the client's users were happily accessing the serial host remotely, additional access was requested. Reports generated on the serial host were required at the remote location. In a typical local application similar to the terminal access described above, printers are attached serially through the same host ports on the serial host. This meant that the same physical connections engineered between the serial host and telnet server could be used for this application as well.

In the case of the terminal access requirement described above, the incoming TCP/IP sessions defaulted to the standard telnet port (or socket) of 23. If we did not make any changes in this area, there would be no way of guaranteeing that the incoming printer session would be directed to a specific physical port on the ETS8 and, consequently, to a specific serial host port. This was important because although the ports used for terminal access were physically the same as those used for printers, there were significant differences in their software configuration. Additionally, we anticipated that multiple printers in different locations would be implemented as part of this project, and we did not want reports generated for one remote location to show up at another.

Fortunately, ETS8 can be configured to associate a service with a particular incoming TCP socket. The range of these configurable socket numbers extends from 4000 through 4999. The following commands are used to establish a new service ("printer") that accepts sessions on TCP socket 4000 and directs them to port 8 on the telnet server.

DEFINE SERVICE printer TCPPORT 4000

DEFINE SERVICE printer PORT 8

Port 8 on the telnet server is connected to a dedicated printer port on the serial host.

Because the printer provided by the client did not contain any native TCP/IP support, a device similar to the protocol-converting telnet server used at the host site was required. This server would be connected between the printer and the IP network at the remote location. One difficulty that presented itself immediately was in the area of session establishment. In the case of the online access requirement, the users directed the establishment of the serial tunnel session and terminated it when it was no longer needed. With the aid of the automatic sign-on script, they could handle any unforeseen problems like network outages and resource unavailability by attempting their access at a later time. We were reluctant to saddle one these users with the responsibility of initiating, monitoring, and maintaining a similar session for each printer. What we needed was a mechanism to establish and maintain the required telnet session automatically.

We were fortunate in that Lantronix' corporate headquarters, together with their engineering and support center, are located within driving distance. We met with one of their applications engineers and together found a solution to the problem of automatic session establishment. Lantronix manufactures a single-port telnet server called the Micro Serial Server or MSS1. Configuring this device is similar to, but not exactly the same as configuring the ETS8. It supports BOOTP and RARP IP address configuration as well.

The first step in configuring the MSS1 was to establish the characteristics of the serial port. Once again, these must match exactly the corresponding setting in the attached serial device (the serial printer in our case). Interestingly they do not necessarily have to match the characteristics of the serial link at the host location.

CHANGE SPEED 9600

CHANGE CHARSIZE 8

CHANGE STOPBITS 1

CHANGE PARITY NONE

Next, we configured the MSS1 to automatically establish a session with the telnet server at the serial host site. This session was directed at the TCP socket configured earlier for the printer service (#4000).

CHANGE DEDICATED TCP 192.168.65.10:4000

CHANGE AUTOSTART ENABLE

Listing 3 shows the output from the SHOW SERVER, and SHOW PORTS commands on the MSS1.

Troubleshooting and Testing

A very important part of any integration project is documentation that includes directions for the diagnosis and isolation of problems that may arise later.

One problem that we anticipated was for the printer to stop printing for no apparent reason. In this situation, you should determine if the problem is (a) at the serial host location, (b) at the remote printer location, or (c) somewhere in-between. These are a few techniques that worked well.

One of the most useful facilities of the MSS1 is the series of startup messages generated at power-up. If these messages successfully print on the printer, we know that the MSS1, the printer, and cable between them is operating properly. The MSS1 does not give a direct indication that is has successfully established a TCP session with the remote server, but TCP session establishment, and thereby the operation of the local area network, can be verified by directing its session to any telnet accessible host. In this case, we used the router located at the serial host location.

CHANGE DEDICATED TCP 192.168.65.1

Without an explicitly specified TCP socket number, the MSS1 defaults to socket 23. When the above command was entered, and the MSS1 was reset, it established a telnet session with the router, and the router's sign-on banner and password request were seen to print out on the printer. This test turned out to be useful in verifying automatic recovery of failed sessions. When the router's password request timed-out, the router terminated the MSS1 initiated telnet session. Undaunted, the MSS1 detected this, re-established the session, and the router's password request was printed again.

Another useful technique is to sign-on to either the ETS8 telnet server or the MSS1 serial server and verify their operation. Both support remote configuration and control from a telnet session to socket 7000.

Summary

To summarize, we've discussed how an IP network can be used to transfer asynchronous data. By implementing a "serial tunnel," using commonly available telnet server equipment and IP-compatible terminal emulation software, network users can access devices without built-in TCP/IP support. Transporting data in this manner can significantly reduce the installation cost and the continuing expense of providing remote communications by consolidating requirements.

I would like to acknowledge the kind assistance of the following people in the implementation of this project: Richard Cole, Brian Crosson, George Hernandez, and Stephanie Yazzie at Packard-Hughes Interconnect; Sandy Dunn at Hewlett Packard; and Lori Weinberg and Danny Wong at Lantronix.

About the Author

Stefan Johnson works at Roncis as a Communications Consultant and is the author of several communications-related articles and papers. With more than 18 years of experience in computer communications and related fields, he specializes in LAN/WAN design and implementation and cross-platform communications support. He can be reached at snsscj1@netcom.com and (909) 594-0013.