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.
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.
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
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.
If CLOCKID != CLOCK_REALTIME, it probably will not have anything to do
with the UNIX epoch, so it could be smaller than 10 digits.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Erik Auerswald
German Service Network
David Schweikert
deepkv
Patrick Ladd
Steven Noonan
deepak0004