fping responses misdelivered on FreeBSD

[clarsen]

On FreeBSD, the PIDs are as large as 99999, so if multiple fping processes are running there's a chance ident4 = PID & 0xffff will collide - which happens on monitoring hosts, like Nagios, that run fping often and simultaneously on a single IP address at a time.

If you have one IP up and one IP down and the two fping's PID ident4s collide, then the process pinging the down IP may see a reply from the up IP.

While the FreeBSD implementation of ping calls connect() which results in echo replies from undesired hosts being dropped before ever being delivered to the process, fping doesn't, so it has to rely on ICMP identifier to filter out the undesired responses.

It appears wait_for_reply() although it filters out ICMP identifier mismatch, it doesn't filter out on source IP address.

[clarsen]

bump on this issue - there's a pull request that fixes this that we've been running with for 18 months or so so far...

[eKrajnak]

I'm experiencing strange issue with fping 5.0 (bullseye repo) on Debian 11 (x64) and I think it colidates with this issue. Fping is used by Zabbix, we spawn 130 pinger processes simultaneously, usually busy for 40-50%, pinging 1k hosts every second (params -C10 -i0 -S [publicip]). Usually after VM reboot, random fping processes report random packet loss for random targets, even when I see icmp response in tcpdump. It's true that we ping a tens of permanently unavailable targets. This situation usually lasts few days, then disappear.

Is this bug affecting Linux distro also? Can we except fix for bullseye repos?
Thank you

[hmh]

Once it is fixed upstream, you have to file a Debian bug explaining the situation, pointing to this bug, and identifying the affected (buggy) versions of fping and the fixed version. Then, it depends on whether the downstream Debian fping maintainer will prepare a debian stable update for fping (possibly backporting only this fix).