Here is how a TCP connection gets established. Lets use port 80 for example. Client connects to server on port 80. Server accept conn and responds saying let's talk on port 12345. This is required so that the server can get rid of the client on port 80 to allow it to accept other connections on port 80 while still talking to the client. The end result is that the client-server interaction post the initial connection occurs on a Socket (Protocol/Port pair) that is to all intents and purposed known only to the client and server. There are therefore really only 2 widgets that can check the connection. The client software or the server software. The OS of course sees all connections but identifying the one you want external to the client-server socket is problematic. As noted the only way to truly validate the functionality of a connection is to send some data across the pipe and get the expected response.

I presume what you are saying is that you can't modify any of the client software, server software or firewall open ports. If this is correct you do have a problem but it can be solved easily enough, provided you can do SOMETHING on the system.

Although nowhere near as robust as passing real data down the socket you can probably check for the physical connectivity of the client. All you need to do is connect to it. Odds on your firewall will allow some external connections to remote ports. Find out which simply by doing a telnet remote.box port At this stage it can be any remote box that accepts connections on that port. Good ports to try are 25, 53, 80 and 110 as SMTP, DNS, HTTP and POP are integral to most systems. Once you have found a port that will pass through the firewall you can set a very simple server on the client - a simple perl server daemon that accepts a connection, prints OK and closes the conn would do. Then just get the server to query it as described and you will prove that the client is still out there.

You have not specified OS but if it is win32 you will find all sorts of open ports on any standard client. For example 25, 110, and 135 will probably accept connections on the client (GOK). This may save you installing anything on the client if it will already accept connections on some ports. Here is a trivial port scanner. If you ran it on the server and substituted 127.0.0.1 for the client address you may just luck out and find a port you can connect to on the client with no extra effort. Then just cron/at it with an appropriate messenger section:

use IO::Socket::INET;

for my $port ( 1..1024 ) {
    $sock = IO::Socket::INET->new(PeerAddr => '127.0.0.1',
                                 PeerPort => $port,
                                 Proto    => 'tcp',
                                 Timeout  => 2);
    print "Port $port ", $sock ? "OPEN\n" : "CLOSED\n";
    $sock->close if $sock;
}
[download]

Here is how a TCP connection gets established. Lets use port 80 for example. Client connects to server on port 80. Server accept conn and responds saying let's talk on port 12345. This is required so that the server can get rid of the client on port 80 to allow it to accept other connections on port 80 while still talking to the client.

that is plain wrong. while some things do negotiate a new port to use for further communication, most do not. doing so makes it extreemly hard to get through firewalls. if a server is going to listen on 80 and then ask client to use 2000-3000 then thats alot of ports that have to be passed inbound by the firewall.

the unique identification of a TCP Session is based on a 4-tuple. (local-ip, local-port, remote-ip, remote-port) that in itself is enough to allow the server to easily talk to multiple clients over the same server side port.

192.168.0.230.22     192.168.0.230.46928  73620      0 65440      0 ES
+TABLISHED
192.168.0.230.22     192.168.81.3.53022   63504      0 63720      0 ES
+TABLISHED
[download]

these are two of my ssh sessions, the client end is random picked port, the server end is always 22. there is no reason to force an incoming client to go to a port other than 22.

now FTP is one of those programs that can use a port in addition to the regular ports, but it's not required. and using a third..nth extra ports is what makes FTP a pain to get across firewalls if you use that functionality.

Hi Tachyon, In using your program to open a socket on a remote specific port from a local specific port, I found that once the connection is closed by Perl, the Solaris system shows the connection in TIME_WAIT state for 5 minutes. This means I can't test the connection again for another 5 minutes. So what I am trying to do is test the connectivity between two specific ports on two different machines through a firewall. Do you know of a way using perl to get around the time wait problem? thanks W3ntp

Change the socket connection to include the following flags:

    ReuseAddr => 1,
    ReusePort => 1,
[download]

This sets SO_REUSEADDR and SO_REUSEPORT before binding so the connection should be released immediately. Note on win32 you probably can't use ReusePort as SO_REUSEPORT is not defined.

cheers

tachyon