Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.12.9) with ESMTP id l3L24UL8013175; Fri, 20 Apr 2007 22:04:31 -0400 (EDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l3L24PQk031902; Fri, 20 Apr 2007 22:04:25 -0400 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l3L24PYs031899 for ; Fri, 20 Apr 2007 22:04:25 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3L24Ndd022769; Fri, 20 Apr 2007 22:04:23 -0400 (EDT) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l3L24Mup021378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 22:04:23 -0400 (EDT) MIME-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: recvmsg, msg_name, and RPC Date: Fri, 20 Apr 2007 22:04:21 -0400 To: krb5-bugs@MIT.EDU X-Mailer: Apple Mail (2.752.2) X-Scanned-BY: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.MIT.EDU Errors-To: krb5-bugs-incoming-bounces@PCH.MIT.EDU X-RT-Original-Encoding: us-ascii Content-Length: 1595 Tom and I have been digging into this a little bit. It appears that some man pages (including Solaris 10) claim that for recvmsg, the msg_name field indicates where the *receiving* address should be recorded, rather than the sender's address as in current documentation. POSIX specs, glibc man pages, Linux 2.6.9 behavior, and Solaris 10 behavior all indicate that it is in fact the sender's address that's returned. And a peek at the 4.3BSD recvfrom source code suggests that perhaps never was implemented that way. So, the new code in the KDC seems to be okay. However, the RPC code we've got calls recvmsg with MSG_PEEK, thinking that it can get the local address, and then calls recvmsg to get the remote address and the data. I instrumented the RPC code in question, and on both Solaris and Linux I found that the so-called local address and the remote address indicated the same address and port. Which means (1) the RPC code is buggy, and (2) probably nothing currently using it cares. For a tiny bit of performance, we could kill the recvmsg call and always store 0.0.0.0. Or use IP_PKTINFO where it's available, but we still wind up with platforms where we can't tell, unless we switch to using a socket per local address like the KDC code does (when IP{,V6} _PKTINFO aren't available). Possibly we might be able to adapt the KDC code to implement the socket listening part of the RPC code, if we separate out the KDC- specific bits. (Even if we don't care about random RPC code, it might be worth doing for kadmind, krb524d, etc.) Ken