In the first half of 2022, I created six pull requests to the fping project at GitHub. Two were merged, the others ignored. They stayed open for a long time.
Having stale old open pull requests on GitHub is inconvenient for me, because it requires keeping a git repository with a fork of the project in my GitHub account. Without any feedback, but with occasional changes upstream, such a fork becomes less useful over time. The patches start to require adjustments, but this seems useless unless there is a visible path forward. (I prefer the older free software workflow of sending patches to mailing lists. It is less overhead, not only when patches stay in limbo for a long time.)
In June 2023, I closed all still open pull requests, since I did not receive any feedback (except from bots). I have put the code changes up as patches on this web page, in case anyone might be interested in them. This should be seen as a kind of archive that can be used for reference.
Please note that I did not update the code changes since creating the pull requests. I do not adjust them to changes in upstream fping. This page is intended as an archive and a reference for anyone interested in the work. It is not intended to provide ready-to-use patches for any released fping version. It is not intended to provide patches that apply cleanly to the current development version of fping, either.
I would be happy to work with fping upstream, or with downstream packagers of fping, to integrate my fping patches. Just send me an email, or comment on any of my issues in the fping issue tracker. Of course, anyone can use my patches to fping without contacting me, this is free software.
Update 2024-02-07: I have resumed making pull requests for fping. I plan to upstream code cleanups and tests first, and also look into one or the other issue. Then I intend to submit new functionality. As a result patches on this web page may become obsolete or no longer apply cleanly.
Update 2024-02-24: Patches on this page may also be obsoleted by different, but equivalent or better solutions.
Two pull requests pertained to fixes for existing issues that fping users stumbled over.
While working on fping issue
#201,
it was noticed that fping would not emit an error message when
getprotobyname() failed. There was an issue comment
asking for a pull request
to address this problem.
Error messages created with crash_and_burn() are suppressed
unless verbose_flag != 0. Socket creation uses this function
to report errors, but the global variable verbose_flag is
automatically initialized to 0 and set to 1 only
after creating sockets. Thus socket creation errors cannot be reported.
The (now obsolete) patch
fping-emit-error-message-when-socket-creation-fails.patch
fixes this by moving the code verbose_flag = 1; before
socket creation.
There might be valid reasons not to move this initialization, but I never received any comment on this simple approach, so I do not know of any.
This patch moves setting verbose_flag = 1 from
after "temporarily" dropping privileges
to before "temporarily" dropping privileges.
An alternative approach could be to use perror() followed
by exit() instead of crash_and_burn().
(This was fping pull request #252.)
The fping code looking for the ICMP for IPv6 protocol value and for opening an IPv6 socket uses error messages identical to the IPv4 code. This makes it impossible for a user to distinguish between IPv4 and IPv6 problems.
Of course, these error messages are never emitted by fping, see the issue identified in a comment to fping issue #201 addressed by another of my patches respectively pull requests.
The (now obsolete) patch
fping-distinguish-ICMP-and-ICMP6-in-error-messages.patch
fixes this by using the actual protocol name ipv6-icmp
used with getprotobyname() instead of icmp
and calling the IPv6 ICMP socket ICMP6 instead of just
ICMP.
I would call this trivial and obviously correct, even though it cannot easily be tested, not only because the error messages are suppressed, but also because one would need an IPv6 build of fping and move that to a non-IPv6-capable system.
(This was fping pull request #250.)
Two pull requests implemented new features for fping. They also contain clean-up patches and additional tests for exiting features that could be applied independently of the new feature work.
There is an old
feature request
(issue #59)
in the fping issue tracker to add IPv6 support to the
-g, --generate option. This option currently only
allows generating IPv4 addresses, from either a network description
in CIDR format or a start and end address.
The following 8 part patch series implements this:
The above patch series has potential for improvement. I would be happy to work with fping upstream towards an acceptable implementation upstream would be willing to merge.
(This was fping pull request #254.)
I opened
issue #243,
Feature Request: Regularly Print Full Statistics Since Start,
in the fping issue tracker to add a new output variation to fping.
With the -Q, --squiet=SECS option, fping prints summary
statistics for the most recent interval every SECS
seconds. I would have liked an option to print summary statistics
since the start of fping every SECS seconds.
Since I do think that both output variants are useful, I suggested to
add a new option to select the new output variant.
The following 5 part patch series implements this by adding a new option
-F, --full for use in combination with
-Q, --squiet=SECS.
The above patch series has potential for improvement. I would be happy to work with fping upstream towards an acceptable implementation upstream would be willing to merge.
(This was fping pull request #244.)
back to my homepage.