[very informal so dropping list]

Sorry, but I had real trouble following what happened.  Could you
explain more precisely?  Perhaps you could walk through the syscalls
on send and receive, mentioning what you see on the wire from tcpdump.

Do you mean that the multicast packet from the client arrives on the
server's socket bound to unicast INADDR_ANY?  That seems odd if it
isn't joined to the group.

  For the multicast-joined address, though, things don't work. I get 
  an error 45 (EOPNOTSUPP) for v6 and 49 (EADDRNOTAVAIL) for v4.

I can't follow what fails, precisely.

  I have a unicast udp address open, bound to port 427 and the unspecified 
  address (0.0.0.0 or :: depending on if I'm using v4 or v6). I also have a 
  multicast address bound to unspecified, port 427, which has joined the 
  right multicast group (for v4, that's IP addr 239.255.255.253, for v6 it's 
  ff0X::123) for locating the discovery agent (the DA).

You mean you called bind(2) with a multicast address?  That could be
the cause of your troubles.  Although odd, I don't think it should explain
what I think you are reporting (but I am not at all sure I understand
what you are saying).

Normal usage would be

  s = socket()
  bind(s, INADDR_ANY, port)
  setsockopt(s, IP_ADD_MEMBERSHIP, [interface], group)

and then packets addressed to the group (on that interface, or if
mrouted is runnin) or a unicast address of the machine would arrive on
the socket.

  Upon closer inspection, the peer address for the received packet always 
  ends up being the unspecified address (0.0.0.0 or ::). So the sendto(2) 
  is a sendto(2) to the unspecified address.

This seems broken (recvfrom returning INADDR_ANY).  But try the above
pattern instead.  sendto(INADDR_ANY) perhaps ought to return EINVAL.

  If the socket is not in a multicast group, the sendto(2) succeeds. If it's 
  in the multicast group, it fails. ??

with a valid peer address each time?
With an invalid dst addr, this is odd -- it ought to fail both times.

  Also, upon failure, the peer address has changed, and now points to either 
  ::1 (v6) or 10.0.0.6 (v4, one of the local IP addrs).

Address changes across sendto(2) call, so that you think the sendto
call is modifying the dst address arg?  That seems very odd.

-- 
        Greg Troxel <gdt@ir.bbn.com>