Sometimes your internet connection may be limited -- think dialup lines or mobile internet. One of the sympthoms is that programs kinda have to wait for the connection to be established, before they can try to connect on layer 4. But as they -- by definition -- don't have a need-to-know what's going on with Layers 2 and 3, they may fail.

So what happens when a program is premature and tries to connect before the uplink is available? It will fail -- either as a name resolution is not possible (no Internet, no DNS resolution except you've added that specific host to you local hosts-file) or simply because a TCP-connecion timeout will occurr or some friendly routing facility informs you by the means of an ICMP message that there's not route to the desired target available.

What's needed is some kind of a little bootloader-like skript which essentially delays the program execution until the uplink is established, a.k.a. "the Internet" (whatever that may be) is reachable.

The solution is as quick-and-dirty as can be -- essentially it's a script that tries to establish a connection using nc with the wait-time set to the minimum:

#! /bin/sh

TARGET=$3
TESTHOST=$1
TESTPORT=$2

nc -w0 $TESTHOST $TESTPORT >/dev/null 2>/dev/null
while [ $? -ne 0 ]
do
        sleep 1
        nc -w0 $TESTHOST $TESTPORT >/dev/null 2>/dev/null
done
if [ ! -z $TARGET ]
then
        echo "$TARGET"
fi
It may be used in two ways: Either as command of its own, or as it allows to pass a parameter to the program to start, as parameter itself:
shell# rdesktop -f `sh wfc.sh my.rdp.host portnum "my.rdp.host:portnum"`
shell# sh wfc.sh my.rdp.host portnum ; rdesktop -f my.rdp.host:portnum
In any case, having to repeat target and port is not satisfactioning but necessary as there's just no ground-breaking standard across programs that using port and host as host:port or as seperate parameters is the way to go.

Stichworte:


Impressum