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

On Fri, Apr 29, 2005 at 04:43:11PM -0700, Bill Studenmund wrote:
> On Fri, Apr 29, 2005 at 07:09:47PM -0400, Greg Troxel wrote:
> >   [very informal so dropping list]
> >=20
> My confusion is that I received a request on socket X and grabbed the pee=
r=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.
>=20
> > the cause of your troubles.  Although odd, I don't think it should expl=
ain
> > 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)
>=20
> I think that's what it's doing.
>=20
> > 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 alwa=
ys=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.
>=20
> I agree it seems broken. Does transmitting a packet over loopback set the=
=20
> "sender" address to that of loopback?

Turns out my printfs were somehow messed up. Now the code's reporting it=20
recvfrom()s the loopback address, and then does a sendto to it.

> >   If the socket is not in a multicast group, the sendto(2) succeeds. If=
 it'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.
>=20
> Yeah...

So we have a valid destdir, and we're a socket bound to unspec in a=20
multicast group.

> >   Also, upon failure, the peer address has changed, and now points to e=
ither=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.
>=20
> I'll double-check I didn't bork something else and that my printfs are=20
> right...

Nope, turns out life's still sane. The address didn't change...

The one thing that may be going on is that when we join the multicast=20
group, we don't specify which interface to use, we use the "default"=20
interface. I bet that's not being remembered right...

Take care,

Bill

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

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

iD8DBQFCcskbWz+3JHUci9cRAtIdAJ9sIjNXxPBG9DKTgRPCXcMMCWBxGgCdGSPh
NWLIfyebi0iTkUasH+Mc7vs=
=OHcd
-----END PGP SIGNATURE-----

--NSDslKtQVY7LeFYu--