by Sandra Henry-Stocker
Networking

Connection testing with Perl

August 21, 2008, 04:11 PM — 

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.

I like it!
Post a comment
The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
Free books

Build your tech library with our book giveaways.

Hacking Exposed, Sixth Edition
By Stuart McClure, Joel Scambray, George Kurtz; Published by McGraw-Hill/Osborne

The original Hacking Exposed authors rejoin forces on this tenth anniversary edition to offer completely up-to-date coverage of today's most devastating hacks and how to prevent them. Using their proven methodology, the authors reveal how to locate and patch system vulnerabilities. The book includes new coverage of ISO images, wireless and RFID attacks, Web 2.0 vulnerabilities, anonymous hacking tools, Ubuntu, Windows Server 2008, mobile devices, and more. Enter now!

Featured Sponsor

AISO founders envisioned a Web hosting company that was environmentally friendly. While the company employed energy-efficient innovations like solar panels, its infrastructure produced unacceptable power and cooling requirements. Find out how AISO leveraged AMD technology to overcome their challenge in this case study white paper.

In this whitepaper, Scalar explores the opportunity to change the landscape with respect to mission critical databases built around Oracle. Leveraging technologies such as Linux, high-end commodity processing power and Oracle RAC technology to architect, design, build and maintain database infrastructure that delivers maximum availability, reliability and performance at a fraction of traditional cost.

On a typical day, weather.com, the Web site for The Weather Channel in Atlanta, serves up between 15 million and 20 million page views. But in September 2004, when back-to-back hurricanes ransacked Florida, the peak traffic on one day more than tripled: over 70 million page views by more than 7 million unique visitors. Read the full success story now.

Marketplace