Subject: Re: Multicast oddity
To: Greg Troxel <gdt@ir.bbn.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-net
Date: 04/29/2005 16:43:11
--KQ2iXOoQ638mtNze
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 29, 2005 at 07:09:47PM -0400, Greg Troxel wrote:
>   [very informal so dropping list]
>=20
> 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.

I'll try. Thank you for attempting to follow-along!

> 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.

Yes, it does.

>   For the multicast-joined address, though, things don't work. I get=20
>   an error 45 (EOPNOTSUPP) for v6 and 49 (EADDRNOTAVAIL) for v4.
>=20
> I can't follow what fails, precisely.

Sorry, the sendto() back to the client.

My confusion is that I received a request on socket X and grabbed the peer=
=20
address. When I go to send back to that peer address on socket X, I get a=
=20
failure sending. When I use a different socket (not in a multicast group)=
=20
with what seems like the exact same addresses, it works.

>   I have a unicast udp address open, bound to port 427 and the unspecifie=
d=20
>   address (0.0.0.0 or :: depending on if I'm using v4 or v6). I also have=
 a=20
>   multicast address bound to unspecified, port 427, which has joined the=
=20
>   right multicast group (for v4, that's IP addr 239.255.255.253, for v6 i=
t's=20
>   ff0X::123) for locating the discovery agent (the DA).
>=20
> You mean you called bind(2) with a multicast address?  That could be

No... Sorry. That's I have the "multicast" socket bound to address=20
unspecified, port 427, which has joined the right multicast group.

> 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).
>=20
> Normal usage would be
>=20
>   s =3D socket()
>   bind(s, INADDR_ANY, port)
>   setsockopt(s, IP_ADD_MEMBERSHIP, [interface], group)

I think that's what it's doing.

> 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.
>=20
>   Upon closer inspection, the peer address for the received packet always=
=20
>   ends up being the unspecified address (0.0.0.0 or ::). So the sendto(2)=
=20
>   is a sendto(2) to the unspecified address.
>=20
> This seems broken (recvfrom returning INADDR_ANY).  But try the above
> pattern instead.  sendto(INADDR_ANY) perhaps ought to return EINVAL.

I agree it seems broken. Does transmitting a packet over loopback set the=
=20
"sender" address to that of loopback?

>   If the socket is not in a multicast group, the sendto(2) succeeds. If i=
t's=20
>   in the multicast group, it fails. ??
>=20
> with a valid peer address each time?
> With an invalid dst addr, this is odd -- it ought to fail both times.

Yeah...

>   Also, upon failure, the peer address has changed, and now points to eit=
her=20
>   ::1 (v6) or 10.0.0.6 (v4, one of the local IP addrs).
>=20
> Address changes across sendto(2) call, so that you think the sendto
> call is modifying the dst address arg?  That seems very odd.

I'll double-check I didn't bork something else and that my printfs are=20
right...

Take care,

Bill

--KQ2iXOoQ638mtNze
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCcsaPWz+3JHUci9cRAgTVAJ9FgijEg2g8WwpxscWmT1pCdCZGvwCdFZ4h
IIHTcpA+IXEYuBxuieKVrn0=
=oOXt
-----END PGP SIGNATURE-----

--KQ2iXOoQ638mtNze--