kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process.

[Robert Watson]

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 
that?

Robert N M Watson
Computer Laboratory
University of Cambridge