MacOSX
And is more than likely to run on any system that's somewhat similar to these.
How does it work?
It's recommended to run ICPLD toward a host that's aware of you doing so, as
constant ICMP requests might be less appreciated by some administrators. This is when the -dinterval switch comes in
handy, as you can use another interval for checking, once the connection is down. And when a working connection is
detected, ICPLD will fall back to either the default interval, or the one specified with -interval.
-dinterval should, however, NOT be lower than 3 seconds, as the timeout for two ICMP packets is ~3 seconds. Setting
dinterval lower, will spawn a pinging process, faster than the old one has been terminated.
The normal way to use ICPLD without a configuration file is as follows:
icpld -ip ip.of.the.target -fbip the.fallback.target.ip
This will fork ICPLD to the background, and send an ICMP request every 10 seconds to ip.of.the.target. If a reply isn't
received within an appropriate amount of time, the connection is considered broken and a stamp is put in the log.
As of version 0.6.0 ICPLD also supports IPv6. In order to perform the same operations, but with IPv6 networking instead, simply
replace -ip with -ip6 and -fbip with -fbip6. Note that all operations available may be applied to IPv6 as well, by simply adding a 6 to the end
of the option.
The log may be read by executing
icpld -log
The log file is by default stored in ~/.icpld/log
Another example would be:
icpld -ip 192.168.0.1 -fbip 192.168.1.1 -interval 15 -dinterval 5 -nd
Which will check if 192.168.0.1 is available every 15 seconds. If it's considered down (it doesn't reply), it will try every
5 seconds. The -nd argument prevents ICPLD from forking to the background, which also makes ICPLD a bit more verbose.
Note that the log will not be 100% accurate, due to timeout time and interval (the lower the interval, the higher
accuracy you will obtain, along with a higher traffic load). It is roughly a few seconds differing at each occasion.
There's several other options available, see 'icpld --help' or 'man icpld' for further information on these.
In the long run, it may become weary with command line arguments. Hence icpld has a configuration file. See
here for further information on using a configuration file with ICPLD.
Why should I run ICPLD / The history
The ICPLD project was born when I moved to a new appartment, and got a new internet connection. It was very unstable, and I got fed up with it.
I wrote a piece of ugly, but still working code, and ran it for a few days. Then I send the log to my ISP, and not only did I get money back for
broken services, but also could they see a pattern in the down times, and fix the problem.