kern/127528: [icmp]: icmp socket receives icmp replies not owned
by the process.
rwatson at FreeBSD.org
Mon Sep 22 08:56:46 UTC 2008
On Sun, 21 Sep 2008, Chris Buechler wrote:
>> This PR is bogus because: ICMP has no concept of datagrams being "owned" by
>> a process. There is no field in the ICMP protocol which differentiates ICMP
>> "sessions" on a per-process basis, and this is because ICMP has no concept
>> of "sessions" -- ICMP messages are directed at IP endpoints.
> ICMP echo and echo replies do have "sessions" of sorts, at least unique
> identifying fields - identifier and sequence number.
> This was opened by a pfSense maintainer because it's a change in behavior
> from 6.x releases where this was never an issue, and is something we feel is
> a regression.
> Ideally you don't want to be pinging the same host from two different
> processes, but it's difficult to avoid in some circumstances and it's
> something that always worked fine prior to FreeBSD 7.0.
As far as I'm aware, IP raw sockets have never supported using the ID field to
identify sessions or direct packets to specific sockets. This means that a
kernel regression in that session semantic is unlikely.
However, it could be that you're seeing the impact of another regression
relating to other behavior for restricting ICMP received on the raw socket.
The kernel code in question is in raw_ip.c:rip_input(), which performs the
following checks for each raw IP socket it considers a candidate for delivery:
- If a non-zero 'protocol' argument was specified in the socket() call, is the
protocol of the packet the same as the protocol on the socket?
- If a local address is bound on the raw socket, is it the same as the
destination address on the packet?
- If a forieng address is bound on the raw socket, is it the same as the
source address on the packet?
- If the socket was created by a process in a jail, is the jail IP the same as
the destination address on the packet?
With these in mind, I'd look for one of two things that might have lead to the
symptoms you're seeing: a change in the way your application is written or run
such that the address limits on packets received are no longer requested or
may now be ambiguous, or a change in the way our system works such that it's
no longer implementing the above checks correctly.
Ping applications are, btw, supposed to select unique identifiers (typically
the pid is used) and then ignore replies with a different identifier, and last
I checked ping(8) did that. Could it be that your application is not doing
Robert N M Watson
University of Cambridge
More information about the freebsd-bugs