Telnet-like TCP/IP Service Testing Run It

What It Does

TestService tests and diagnoses many different Internet services. It connects to them in a debugging mode and lets you control them directly while watching what they do. These services include HTTP/HTTPS (web servers), SMTP/SMTPS (email), and POP/POPS and IMAP/IMAPS (PC email).

Telnet Testing Made Easy

Many technical people know they can use telnet from a command line to open and interact with certain Internet services. If you search for how to solve a problem with an Internet service, frequently the answer describes how to use telnet to troubleshoot. Because it also works on the secure (SSL) versions of these services, decripting the traffic so you can see it, it can test things that are impossible with telnet.

Using telnet in this way is an exacting science however. The lines you type into telnet have to be done in the correct order with no typos, and they have to be entered quickly before the server, which is used to talking to another computer, times out and disconnects you. Which typically means every time you want to test something you have to go lookup the command sequence and then try it several times to get it right. During a test/debug session, you type those same commands over and over.

TestService does two things to make this process easier. One, it has a "template" for most Internet services that has the commands and arguments in the right order. Two, it lets you change the template and save your changes, so you can use it over and over without retyping.

Available Templates

Simple Internet Email
Extended SMTP
Secure SMTP
Secure ESMTP
SMTP alt port
ESMTP alt port
ESMTP alt port with TLS
Post Office Protocol
Secure POP
Internet Message Access Protocol
Secure IMAP
Hyper Text Transport Protocol (web server)
Secure HTTP

How To Use It

Using TestServer is typically an iterative process. First you create a Command Set by loading a template and customizing it. You then run it repeatedly as you modify the service and the Command Set until the service is working the way it should. Each run displays the Commands and service output, then redisplays your Command Set making it easy to repeat.

The initial customizations to the template include entering the IP address of the server on which the service is running, and entering valid userids and passwords if the service requires authentication. The on-going modifications include changing up the commands being sent in order to test different features and scenarios of the service.

The initial TestService screen (below) shows an empty Command Set and a pull-down menu of available templates. You can build your own Command Set by adding Steps (i.e. commands) manually, or you can load a template to give you a head start. To build a Command Set from scratch, click Add Last to insert a new Step. To use a template, select one from the pull-down list and click Load.

The buttons on the TestServer screen are straightforward:

Redisplays the Step table, cleans up the formatting
Runs your test, displaying the output in real time, and redisplays the Command Set
Starts over with an empty Command Set
Displays these instructions
About Tests
Displays an overview of all tests
Clears existing Steps and loads a new Template
Add Last
Appends a new (empty) last Step
Inserts a new (empty) Step above this one
Deletes this Step

Command Set Steps

A Step is one of "Send", "Read", or "Do", which respectively send a command or data to the service, read something from the service, or change something about the connection.

Steps are listed in a table on your screen:

Has Ins and Del buttons to insert and delete steps
"Send", "Read", or "Do"
Used only for "Read": how long (seconds) to wait for a response from the service
for "Send", the string to send
for "Read", a string to look for (i.e. stop reading when it sees this)
for "Do", the action to perform (StartTLS, SetStepTimeOut, SetTestTimeOut)

A "Send" step sends the Data string to the service.

A "Read" step reads output from the service until it finds the string in Data, or until the TimeOut seconds have passed. Technically, the Read string is a simple Regular Expression . For simple testing, you can skip the string (i.e. leave Data blank on the "Read" Step) and just use the TimeOut to end the read. Thirty (30) seconds usually works. Your test will take 30 seconds between Steps, but it will work.

For faster tests or where the TimeOut is not sufficient, you can enter a string (regex) into the Data field. The test will stop reading as soon as it finds that text in a line from the service (i.e. the regex matches). The string (regex) you enter does not have to be at the end of the line -- just find a unique word or string in the last line of what the service sends. Because most services return just one line per command step, oftentimes it is sufficient to use just "\n" (without the quotes) as the wait-for string. See various Templates for more information.

In both Send and Read strings, simple escape sequences are used for newlines, control characters, etc. These are "\n" for newline, "\r" for return, "\t" for tab, and "\x00" for any other non-printing character, where 00 is the hex code for the character. So to send an SMTP "HELP" command, the Data would be "HELP\n" (without the quotes). If the service sends a control-C, it would show up in the output as "\x03" and could be matched with the same string. See some of the Templates for more examples.

The valid "Do" actions are:
"StartTLS" - switches the connection from plain text to SSL/TLS encryption
"SetStepTimeOut" - sets the default Read timeout (seconds) (can be overridden on a specific Read Step)
"SetTestTimeOut" - sets how long the whole test can take (seconds) (limited to 5 minutes)

A sample Template looks like this on your screen:


The output shows the commands you sent and the responses from the service. Commands and data sent from you are prefixed with "-->", and responses sent from the server are prefixed with "<--". Other than that, no annotation or formatting is added, and no data is deleted or suppressed. For example:


We do not store your test on our servers. Between runs, the only place your template exists is in the browser window on your PC. Still, we recommend using test data rather than real, high security data when using TestService. While we maintain high security standards, we will not assume responsibility to protect userids or passwords you use in testing.

The core of TestService is a java application that we make available for custom use. This includes testing private connections that are not Internet accessible, long term visibility into client/server communications, watching very sensitive data, etc. Contact us for more information.