Release 5.3

[schweikert]

Let's try using a "discussion" to prepare the next release.

• I will take care of preparing "rc" releases with tarballs that can be tested.
• We can discuss any pending required work.
• @auerswal @gsnw-sebast I suggest that you put here a comment with a "thumbs up", as soon as the release looks ok as-is.

Latest rc-release tarball: https://fping.org/dist/beta/fping-5.3-rc1.tar.gz

[gsnw-sebast]

I can do a basic test based on fping-3.5-rc1

Systems

• Debian-i386
• Debian-i386-docker
• Debian-arm64
• FreeBSD 14.2-amd64
• Microsoft WSL Ubuntu (Build test only)

Hope other users might also be able to test

[gsnw-sebast]

All tests done with fping-3.5-rc1, fping-3.5-rc2 and 48bf234

[auerswal]

👍 Looks good to me. I have looked at the changes to prepare the release, and have tested fping 5.3-rc1 on Ubuntu 20.04 LTS without problems.

[auerswal]

Just noticed a small potential change for CHANGELOG.md: would it make sense to move the last entry from the ## Bugfixes and other changes section to the ## New features section?

[ - Print cumulative stats with -Q SECS,cumulative (#315, thanks @auerswal) ]

I'd think this is more of a "new feature" than an "other change" (and it's no bug fix).

[auerswal]

Both options --print-ttl and --print-tos are new features for 5.3. Should we address GH issue #367 concerning the combination of those options with -c, -C, and -l in this release?

As a first step, I have created draft pull request #368 that handles printing TOS and/or TTL with -c, -C, and -l. It rearranges the output code and unifies some parts of normal vs. per receive output. I did not change the existing output format of --icmp-timestamp, but it differs between default output and per receive (i.e., -c, -C, and -l), while it could also be the same (this is also new for 5.3).

The draft PR does not yet add TOS and/or TTL to -Q output. I'd say that allowing the combination of -Q with --print-tos and --print-ttl should also be added.

[edited to remove part regarding -Q, see GH issue #367 for additional information]

What do you think?

[gsnw-sebast]

We should add this and then create an rc2

[schweikert]

I agree that we should try to finalize any output tweaking before doing the release.

I released 5.3-rc2: https://fping.org/dist/beta/fping-5.3-rc2.tar.gz

[auerswal]

I agree that we should try to finalize any output tweaking before doing the release.

I would prefer the ICMP Timestamp output to be the same for both general fping operating modes. Currently we have two slightly different formats.

Neither count nor loop:

$ fping --icmp-timestamp 127.0.0.1
127.0.0.1 is alive (Timestamp Originate=66093454 Receive=66093454 Transmit=66093454 Localreceive=66093454)
$ fping --alive --icmp-timestamp 127.0.0.1
127.0.0.1 (Timestamp Originate=83148844 Receive=83148844 Transmit=83148844 Localreceive=83148844)

For count or loop modes:

$ fping --icmp-timestamp -c1 127.0.0.1
127.0.0.1 : [0], 20 bytes, 0.085 ms (0.085 avg, 0% loss), ICMP timestamp: Originate=66101675 Receive=66101675 Transmit=66101675 Localreceive=66101675

127.0.0.1 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 0.085/0.085/0.085
$ fping --icmp-timestamp -C1 127.0.0.1
127.0.0.1 : [0], 20 bytes, 0.076 ms (0.076 avg, 0% loss), ICMP timestamp: Originate=66258694 Receive=66258694 Transmit=66258694 Localreceive=66258694

127.0.0.1 : 0.076
$ fping --icmp-timestamp -l 127.0.0.1
127.0.0.1 : [0], 20 bytes, 0.053 ms (0.053 avg, 0% loss), ICMP timestamp: Originate=66270891 Receive=66270891 Transmit=66270891 Localreceive=66270891
^C
127.0.0.1 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 0.053/0.053/0.053

TOS and TTL are printed in front of the timestamp, but elapsed time (-e, --elapsed, only without count/loop) is printed after the timestamp:

$ fping --icmp-timestamp --print-ttl --print-tos --elapsed 127.0.0.1
127.0.0.1 is alive (TOS 0) (TTL 64) (Timestamp Originate=66451176 Receive=66451176 Transmit=66451176 Localreceive=66451176) (0.061 ms)
$ fping --icmp-timestamp --alive --print-tos --print-ttl --elapsed 127.0.0.1
127.0.0.1 (TOS 0) (TTL 64) (Timestamp Originate=83423492 Receive=83423492 Transmit=83423492 Localreceive=83423492) (0.031 ms)
$ fping --icmp-timestamp --print-ttl --print-tos -c1 127.0.0.1
127.0.0.1 : [0], 20 bytes, 0.091 ms (0.091 avg, 0% loss) (TOS 0) (TTL 64), ICMP timestamp: Originate=66485525 Receive=66485525 Transmit=66485525 Localreceive=66485525

127.0.0.1 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 0.091/0.091/0.091

I would like to change two three things about this:

1. print TOS and/or TTL after the timestamp and before the elapsed time,
2. always print the timestamp as ", timestamps: Originate=<number> Receive=<number> Transmit=<number> Localreceive=<number>" for normal operation and count / loop modes,
3. print the timestamp as "timestamps: Originate=<number> Receive=<number> Transmit=<number> Localreceive=<number>" for fping --alive --icmp-timestamp (no leading comma)

[edited to add -a, --alive considerations]

If this is OK for for you, @schweikert and @gsnw-sebast, I can prepare a pull request with the required changes (including adjusted test cases).

[gsnw-sebast]

We can do it like this. At the time, I had oriented myself 1:1 to hping3. With the exception of hping3, the output is always written to a new line.

[auerswal]

See pull request #371.

[gsnw-sebast]

I looked at it and it looks good.
In general I have something against long outputs if all three parameters --icmp-timestamp, --print-ttl and --print-tos are used.
This is probably the reason why hping3 writes this to a new line.
But my first version was worse

[auerswal]

I'd think that having all output regarding to one received ICMP reply in a single line makes programmatically parsing the output simpler. Always using the same output, as opposed to changing to a multi-line format if too much output is requested, also helps for this. (hping3 only supports a single target host, so all output pertains to that host. This makes it less important for hping3 to keep the output in one line, I'd think.)

[schweikert]

I released fping 5.3-rc3

[gsnw-sebast]

• Debian-i386
• Debian-i386-docker
• Debian-arm64
• FreeBSD 14.2-amd64
• Microsoft WSL Ubuntu (Build test only)

[auerswal]

5.3-rc3 looks good to me. :-)

(Just to help remembering: version number and date at the top of CHANGELOG.md need to be adjusted for the 5.3 release.)

[gsnw-sebast]

My tests all ran without errors. I have no objections to the provision of the final version 5.3