Duplicate reply packets when pinging multiple targets
Giux3 opened this issue · comments
Masking first 2 octets (A.B)
on v 4.0 was ok
A.B.116.146 is alive
A.B.142.68 is alive
A.B.108.7 is alive
A.B.155.155 is alive
A.B.141.100 is alive
A.B.144.164 is alive
A.B.156.69 is alive
A.B.109.230 is alive
A.B.140.88 is alive
A.B.156.167 is alive
A.B.144.81 is alive
A.B.143.98 is alive
A.B.143.173 is unreachable
on v 5.1:
A.B.116.146 is alive
A.B.142.68 is alive
A.B.156.167 is alive
A.B.108.7 is alive
A.B.144.164 is alive
A.B.144.164 : duplicate for [0], 64 bytes, 65.4 ms
A.B.141.100 is alive
A.B.141.100 : duplicate for [0], 64 bytes, 116 ms
A.B.155.155 is alive
A.B.155.155 : duplicate for [0], 64 bytes, 45.4 ms
A.B.156.69 is alive
A.B.156.69 : duplicate for [0], 64 bytes, 197 ms
A.B.109.230 is alive
A.B.140.88 is alive
A.B.109.230 : duplicate for [0], 64 bytes, 144 ms
A.B.140.88 : duplicate for [0], 64 bytes, 138 ms
A.B.144.81 is alive
A.B.143.98 is unreachable
A.B.143.173 is unreachable
test was done behind same switch on two different machines
( mint 19.3 fping/bionic,now 4.0-6 amd64 VS ubuntu 22.04 lts fping/jammy,now 5.1-1 amd64)
sorry for pinging , hoping for a reply...
is this expected and normal behaviour on slow links?
Seeing the same thing after switching from Alma Linux 8 with fping 4.2 to Ubuntu 22.04 LTS with fping 5.1-1. Looking for way to downgrade now as this is causing a lot of false alerts in our Icinga platform.
i what why ? [1], timed out (NaN avg, 100% loss)
I do not see this problem when pinging multiple targets. I would assume that fping reports actual duplicate packets, i.e., I would expect fping to work correctly. I would expect that a packet capture (using, e.g., tcpdump) would show these duplicate reply packets.
Since the reports about duplicate reply packets are sent to standard error while the normal output (alive and unreachable) goes to standard output, you might be able to ignore the reports of duplicates by redirecting standard error:
fping ... 2>/dev/null
that can be fine despite the redirection of other useful messages with the solution provided
however there is something different in the behaviour of v. 4 vs 5.1 maybe more evident over slower networks
If the behaviour is expected is ok but confirmation is welcome
Showing duplicates is expected behavior and I assume that this is working correctly (I don't know why there is a difference with 4.0, which is quite old). If it is wrong, can you verify with tcpdump or similar that you are not getting duplicate responses? I will close this for now.