--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 30, 2005 at 01:50:32PM -0700, Jonathan Stone wrote:
>=20
> In message <20050430141629.0F90B1F42@fnord.ir.bbn.com>,
> Greg Troxel writes:
>=20
> >  How in the world did we go from unbound sending to 10.0.0.6 to having a
> >  multicast (239.255.255.253) address as our source!
> >
> >I think you are converged, but this sort of follows from binding to a
> >multicast address.
> >
> >You might file a PR that the bind-to-multicast succeeded, although
> >reading in_pcbbind() it seems that it is intended to do something
> >useful.  Perhaps the intent is to get only packets for that group, and
> >not to affect the outgoing source address process.  But it really
> >seems like something is broken in the kernel.
>=20
> I concur. From Bill's description of what the Linux code does, I can
> construct a similar guess at the intended behaviour.=20

Note: I'm inquiring as to the nature of the change. I am not certain that
the code isn't broken. This exact behavior came into the OpenSLP code in a=
=20
fix that was supposedly improving Windows support, yet the non-windows=20
behavior changed...

> But I'd argue that:
>=20
> a) sending packets with a multicast source address is absolutely
> verboten: for IPv4, see rfc-1112, sec 6.2.
>=20
> b) The semantics of bind(2) are clearly specified as binding a
>    source address; not some side-effect for multicast, as Greg
>    and I are imagining.
>=20
> So I conclude that --- unless there's some well-defined reason (e.g.,
> an RFC specifying socket API for multicast which specifies this
> side-effect for bind(2)?) --- that bind(2) with a multicast address
> SHOULD return an error: EADDRINUSE, or maybe EACCESS (whatever meets
> SPEC 1170 and SUS.)

I think the EADDRNOTAVAIL error seems best. That's what v4 does when you=20
try to send with such a beast.

> Even if we do that, bind(2) with a multicast address probably
> needs to be Linux-specific, if our (Greg and my) guesses about intended
> behaviour are correct, and Linux does something particular (e.g.,
> default-address?)  for bind(2) with a multicast address.

Let me double-check that this code really is trying to make something work=
=20
on Linux, and isn't just confused.

Take care,

Bill

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

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

iD8DBQFCdUrZWz+3JHUci9cRAiEtAJ9q/Nt2qRHQEDqWJlmFh0U+s/jtKwCgh2qt
G4xU5udl75K3nNnu2ozLxag=
=/6Q+
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--