Americas

  • United States
sandra_henrystocker
Unix Dweeb

Connection testing with Perl

Analysis
Aug 21, 20084 mins
Data CenterLinuxNetworking

Since I’m seldom in control of all the devices between myself and whatever system I am trying to reach, I often like to verify whether I will be able to connect to a particular port on the particular system before I concern myself with whether my connection is behaving as it should. For example, I can use a command such as “telnet remhost 9999” and then try to determine if the response I am getting is the one I was expecting. If I have appropriate access to both systems, however, I can start a process on the particular port I want to reach and then run a test to see whether I can reach that process from the other system.

A little expertise with socket I/O can come in very handy for this kind of testing. You can get by, however, with a short but handy sample Perl script like one that I have used for many such tests over the years. I call my script, derived from many Perl command examples that I’ve encountered on the web, “listen”. Listen will open any (non-busy) port above 1023 for a normal user and any (non-busy) port for root. It requires the Socket module for the muscle work and for definitions of most of the variables used (e.g., SOCK_STREAM).

The port that you want to open must be passed as an argument or the script will complain and immediately exit.

To test a port, you would type “./listen 9999” or something like that on one system and “telnet localhost 9999” on the same server or “telnet remhost 9999” (replacing “remhost” with the actual host name of the target system) on a remote server. You should see a message acknowledging your connection on the telnet side.

boson> telnet fermion 9999 Trying 127.0.0.1… Connected to fermion. Escape character is ‘^]’. —————————— You have connected to fermion —————————— Connection closed by foreign host.

The script itself uses a series of commands to set up the socket, starts to LISTEN on that socket and sends the simple “You have connected” message to systems that connect to it.

#!/usr/bin/perl -w

use strict;
use Socket;

my $port = shift or die "no port specified";
my $proto = getprotobyname('tcp');
my $sysname = `uname -n`;

# create socket
socket(SERVER, PF_INET, SOCK_STREAM, $proto) or die "socket: $!";
setsockopt(SERVER, SOL_SOCKET, SO_REUSEADDR, 1) or die "setsock: $!";

# local port
my $paddr = sockaddr_in($port, INADDR_ANY);

# bind and listen
bind(SERVER, $paddr) or die "bind: $!";
listen(SERVER, SOMAXCONN) or die "listen: $!";
print "SERVER started on port $port ";

# accepting a connection
my $client_addr;
while ($client_addr = accept(CLIENT, SERVER))
{
# who is connecting?
my ($client_port, $client_ip) = sockaddr_in($client_addr);
my $client_ipnum = inet_ntoa($client_ip);
print "connection from: $client_ipnum";

# print message, close connection
print CLIENT "------------------------------n";
print CLIENT "You have connected to $sysname";
print CLIENT "------------------------------n";
close CLIENT;
}

The services that you intend to connect to on the target system are likely to be far more sophisticated than this basic Perlscript that just issues a reaffirming message and hangs up, so it may be far more difficult to interpret their responses as signifying success. Using a listen script of this sort, on the other hand, means you can get confirmation of your basic ability to connect to the remote system. You can then get your mind off wondering whether network and firewall restrictions might be interfering with what you’re trying to accomplish and onto the more the painstaking testing involved with verifying whether your application is working properly.

Over the years, I have found this kind of script to be invaluable — something like a software version of a cable tester — and suspect it belongs in every sysadmin’s bag of tricks. If you have never used this kind of script to verify connectivity, you might consider running some tests to see how easy it is to take advantage of the very useful Perl Sockets module for everyday testing.

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author