This commit does not add tests that verify the exact limit,
because pinging 100000 localhost addresses takes over 15
minutes on my PC. I have tested this fix manually.
As described in GH issue #299, the MAX_GENERATE+1 limit is only
applied when using an address range, not when using CIDR. This
commit changes this to always honor the generator limit.
* refactor target address generation to use the same new function
for both range and CIDR notation
* check the limit for addresses to generate in the new function
* document the generator limit in "fping --help" output
* document the generator limit in the fping man page
* test that the address generation limit applies when using CIDR
notation
Sometimes, this test fails on macOS, at least on the GitHub CI.
It looks as if the fping process is killed before it produces
the required output. This test works reliably on GNU/Linux, so
keep it, but skip it when running on macOS.
Some changes of fping resulted in some systems reporting
implausible timestamps, see, e.g., GH issue #203. This
commit adds a simplistic plausability check for timestamps
in Unix time format: they need to be greater or equal to
1000000000 (2001-09-09 03:46:40+02:00).
Test "fping -S" with both IPv4 and IPv6 addresses not configured
on local interfaces using addresses reserved for documentation.
Check the fping error message, but accept any system generated
additional information. This additional information differs
between operation systems.
The existing test for "fping -h" triggers the special code path
for only one option, either -h or --help, that is handled before
normal option parsing.
With -Q SECS, fping emits information for the just finished
interval. This is good for long-running fping processes where
one would like to get an update on recent results, ignoring
missing responses from older intervals. This seems appropriate
for use with other software like netdata or smokeping.
But for short(er)-running fping processes, e.g., during a change
window, it may be more interesting to get a status update since
the beginning of the change window, i.e., the start of fping.
Adding a comma followed by the keyword "cumulative" to -Q SECS
(i.e., -Q SECS,cumulative) changes the interim reports to output
the current per system overall statistics, unless -N is used, too.
The new syntax is documented in fping.pod and added to fping -h
output.
Four tests are added:
1. Characters after SECS are ignored as before.
2. Unknown keywords are ignored as before.
2. Adding ",cumulative" changes -Q output.
3. Adding ",cumulative" also affects the additional -o output.
This addresses issue #243.
Remove the 'fping -X 2 --generate 8.8.0.0/29' test, because it
is currently failing on the MacOS runner. Also, I am not sure that
it is a good idea to ping the IPs 8.8.0.1 and 8.8.0.2 and rely on
them being up.
Git commit bb8d71ef27 from 2020 among many
other things introduced the function stats_reset_interval() to reset the
*_i interval (or split) host statistics, but did not use it. This commit
replaces the open coded reset of interval stats inside print_host_splits()
and print_netdata() with calling stats_reset_interval().
As mentioned in issue #300, error messages pertaining to
socket creation may not be printed. But they should be
corrected anyway, just as the comments. Having correct
error messages also makes a fix for issue #300 more
obvious, because the messages itself would not change.
As described in issue #295, the option combinations "-c N -u"
and "-c N -a" inadvertently have the same effect as "-c N -q".
Prevent this by first acting on -c, which includes disabling
either -a or -u, if -c is given, before acting on -a/-u.
The -i MSEC, --interval=MSEC option does not directly affect
the output format, but rather the probe generation, i.e., the
minimum time between probes. Thus it is more fitting to list
it under "probing options" than under "output options".
Any Echo Response packet uses a different source address than
used for the target, because it is not allowed to use a multicast
address as source. This results in extra output in a specific
format on standard error.
This should work, because IPv6 requires multicast support, and
every IPv6 node is supposed to join the "all nodes" multicast
group, including the node the test runs on. It at least works
on my Ubuntu 20.04 LTS system.
* -f with non-existing file
* -f with input file containing comment and empty line
* -g with non-numeric address in "CIDR" format
* -g with one non-numeric address in start resp. end position
* -g with one IPv6 address in start resp. end position
In the function print_per_system_stats(), if packets have been
lost, the number of sent packets is checked to be positive before
dividing by it. If no packets have been lost, this is not checked.
Either the existing check is not needed, or both code paths need
the check.
The function print_per_system_splits() is quite similar to
print_per_system_stats(), and has the equivalent guards against a
division by zero in both code paths, not just one of them.
In the spirit of defensive coding, I think it is better to be safe
and add the missing guard against a division by zero.
With the options -x and -X, fping does not require all hosts to
be reachable for an exit status of 0.
This addresses a comment in issue #99 suggesting such a man page
update.
The man page gives two examples combining -C and -q, but
these combinations are not yet tested. Add tests to help
ensure the documented examples continue to work.
The statistics printed every SECS seconds show the results
since the the last report, not since the beginning. Also,
every report starts with a timestamp.
* wrong number or kind of arguments fails and prints usage;
* an empty range silently pings nothing and fping returns 1;
* a too large range fails with an error message;
* a zero CIDR prefix length fails with an error message.
Erik Auerswald
German Service Network
dwes
David Schweikert
deepkv