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

[Robert Watson]

The following reply was made to PR kern/127528; it has been noted by GNATS.

From: Robert Watson <rwatson at FreeBSD.org>
To: Chris Buechler <cmb at pfsense.org>
Cc: freebsd-net at FreeBSD.org, remko at FreeBSD.org,
	"Bruce M. Simpson" <bms at FreeBSD.org>, freebsd-bugs at FreeBSD.org
Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not	owned
 by the process.
Date: Mon, 22 Sep 2008 09:56:45 +0100 (BST)

 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
 _______________________________________________
 freebsd-net at freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"