Possible ICMP reply misdelivery or identifier collision in ping on FreeBSD 14.4

[sika]

Hi,

I’ve run into something odd with ICMP/ping behavior on a FreeBSD system and wanted to check if anyone else has seen this.

System version:
FreeBSD 14.4-RELEASE-p5

This is a monitoring server that runs a fairly large number of concurrent ping checks. In total I’m continuously pinging around 100 different targets. All ping requests originate from the same thin jail.

Example:

# ping -o 192.168.11.50 && echo $?
PING 192.168.11.50 (192.168.11.50): 56 data bytes
64 bytes from 18.165.122.41: icmp_seq=0 ttl=63 time=750.555 ms

--- 192.168.11.50 ping statistics ---
1249 packets transmitted, 1 packets received, 99.9% packet loss
round-trip min/avg/max/stddev = 750.555/750.555/750.555/0.000 ms
0

# freebsd-version
14.4-RELEASE-p5


What caught my attention is that the reply is coming from a completely different IP (18.165.122.41), even though the ping target is 192.168.11.50.

This seems to indicate that an unrelated ICMP reply is being picked up by this ping process.

Some observations:
- The system is generating a moderate amount of ICMP traffic (around 100 monitored hosts)
- This happens intermittently
- Only one reply is received, and it is clearly not from the intended target
- The process still exits successfully due to `-o`

My question:
Has anyone seen cases where ICMP replies get "misdelivered" to the wrong socket/process under this kind of load on FreeBSD?

Or is there something about how `ping` matches replies (e.g. identifier collisions, raw socket behavior, etc.) that could explain this?

Any ideas or pointers would be appreciated.

 

[sika]

A follow-up to my own thread in case someone else runs into this:
Based on closer analysis, this appears to be related to ICMP identifier collisions rather than any actual packet misdelivery in FreeBSD.

The ICMP echo identifier is only 16 bits, so in an environment like this (around 100 concurrent ping processes from the same host/jail), it is at least possible that two processes use the same identifier value at the same time. In the case of ping -o, the sequence number is usually just 0 as well, so it adds very little additional uniqueness.

In such a situation, a reply for one target may end up being handled by another ping process if they happen to share the same (id, seq) combination. Since -o exits on the first response, even a “wrong” reply is enough to make the command appear successful.

So what looks like a reply coming from the wrong IP is most likely a valid ICMP reply that just gets matched to the wrong process due to identifier reuse. This seems more like a limitation of the matching logic combined with the 16-bit ID space under load, rather than an actual FreeBSD bug.