Inconsistent limits for address generation via -g, --generator using either range or CIDR

[auerswal]

When using fping -g with a range, the number of addresses that may be generated is limited (via the MAX_GENERATE constant in src/fping.c):

$ fping -q --stats -g 127.0.0.1 127.1.255.254
./src/fping: -g parameter generates too many addresses

But this limit is not applied when using CIDR notation:

$ ipcalc 127.0.0.0/15 | grep 'HostM[ai][nx]'
HostMin:      127.0.0.1
HostMax:      127.1.255.254
$ fping -q --stats -g 127.0.0.0/15

  131070 targets
  131070 alive
       0 unreachable
       0 unknown addresses

       0 timeouts (waiting for response)
  131070 ICMP Echos sent
  131070 ICMP Echo Replies received
       0 other ICMP received

 0.005 ms (min round trip time)
 0.033 ms (avg round trip time)
 0.166 ms (max round trip time)
     1328.103 sec (elapsed real time)

I have mentioned this in a comment on issue #59, because I think that applying a consistent limit to address generation is a prerequisite for expanding -g functionality to include IPv6, but I'd prefer to track this issue independently.

I can refresh my respective patches that have been part of the IPv6 generator pull request #254 and submit them as a new pull request. Just let me know if this desired.

[auerswal]

To collect relevant information in one place:

• The restrictions for address generation are not documented (neither man page nor --help output mention them).

• There is also an inconsistency (off-by-one) in the comment describing the constant used to limit address generation when using start and end addresses:

  $ git grep -n MAX_GENERATE
  src/fping.c:142:#define MAX_GENERATE 100000 /* maximum number of hosts that -g can generate */
  src/fping.c:1342:    if (end_long > start_long + MAX_GENERATE) {
  $ ./src/fping -q -s -g 127.0.0.1 127.1.134.162
  ./src/fping: -g parameter generates too many addresses
  $ ./src/fping -q -s -g 127.0.0.1 127.1.134.161
  
    100001 targets
    100001 alive
         0 unreachable
         0 unknown addresses
  
         0 timeouts (waiting for response)
    100001 ICMP Echos sent
    100001 ICMP Echo Replies received
         0 other ICMP received
  
   0.006 ms (min round trip time)
   0.032 ms (avg round trip time)
   0.321 ms (max round trip time)
       1012.501 sec (elapsed real time)
  
  

[auerswal]

Another point to consider: Using --generate with a large CIDR subnet can result in problems, e.g., using too much memory:

$ ./src/fping -q -s -g 127.0.0.0/8
Killed
$ dmesg -t | grep -E '^(oom-kill|Out of memory)'
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected],task=fping,pid=10558,uid=1000
Out of memory: Killed process 10558 (fping) total-vm:5346240kB, anon-rss:5343568kB, file-rss:172kB, shmem-rss:0kB, UID:1000 pgtables:10504kB oom_score_adj:0

Therefore I'd say that having a limit is useful.

[gsnw]

Have you found a solution to the problem?
If not I would try to help

[auerswal]

Yes, I already have a (partial) solution to this as part of an older, now closed, pull request. I'll try to find the time to adapt it to the current fping code, and add the missing pieces (adjust the limit to a power of two to better fit CIDR notation and document the limit in the man page (i.e., fping.pod)).