Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Intercepting Telnet Data

IP.com Disclosure Number: IPCOM000104959D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 137K

Publishing Venue

IBM

Related People

Kolban, N: AUTHOR

Abstract

When a user of a software system discovers a problem, he may contact a software support center for assistance. However, the software problem may be unreproduceable; the sequence of steps may have been forgotten or he may not be able to communicate the problem in a manner that support personnel can work with. Ideally, the user should have a record of all inputs and outputs which could be given to the support personnel to unambiguously determine the symptoms and path of the problem.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 42% of the total text.

Intercepting Telnet Data

      When a user of a software system discovers a problem, he may
contact a software support center for assistance.  However, the
software problem may be unreproduceable; the sequence of steps may
have been forgotten or he may not be able to communicate the problem
in a manner that support personnel can work with.  Ideally, the user
should have a record of all inputs and outputs which could be given
to the support personnel to unambiguously determine the symptoms and
path of the problem.

      This article describes such a facility which allows user/host
interaction to be manipulated in a way previously unavailable.  It is
based upon the protocols described in the Telnet specifications
available in the public domain Request For Comment (RFC) document 854
[*].  The protocol specifies flows and architectures for remote
terminal emulation and connection.  Telnet has been implemented on
top of the TCP/IP networking protocol on every implementation and
operating system.  In addition to RFC 854, a number of additional
RFCs have been written relating to the telnet protocols including TFC
885 - Telnet End Of Record, RFC 856 - Telnet Binary Transmission, RFC
930 - Telnet Terminal Types.  The introduction of these RFCs made
possible telnet applications which can emulate IBM 3270 Data Stream
terminals.

      Features of the facility are the ability to capture session
data from a telnet client to a telnet server so that data can then be
stored and analyzed; capability to play-back captured sessions to
re-create known software states and as a framework for a software
regression testing tool.  It requires no modification to either
telnet clients, servers or applications to be executed and can
provide performance analysis of response times.  By intercepting the
data flows between the telnet clients and servers, user interaction
and host response can be captured, analyzed and replayed.  The scheme
could be used with many operating systems, applications and purposes.
Since telnet is supported on most operating systems and telnet
clients are able to emulate 3270 Data Stream terminals it could be
employed on non-ASCII systems including MVS and VM.

      If a data interceptor is placed between the telnet client and
telnet server, the data transmitted from each can be manipulated.
Fig. 1 shows such an insertion.  Both the telnet clients and telnet
servers use the TCP/IP socket libraries for communication with each
other.  The data interceptor also uses sockets and looks like a
telnet server to a telnet client and a telnet client to a telnet
server.  When a telnet client attempts to communicate with a telnet
server, a TCP socket connection is formed.  Both the client and
server expect to receive specific protocol information.  The data
interceptor mechanism works by intercepting the connection request
from the telnet client and forming the connection with the server on
the client's behalf.  It then forw...