Ticket History #5540: recvmsg, msg_name, and RPC

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