Subject: Multicast oddity
To: None <tech-net@netbsd.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-net
Date: 04/29/2005 13:31:25
--E5HUUwS3R9LcK7+r
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

As everyone probably knows, I'm playing with OpenSLP.

I'm seeing some very strange behavior with the daemon.

I have a unicast udp address open, bound to port 427 and the unspecified=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 it's=
=20
ff0X::123) for locating the discovery agent (the DA).

When the client on this host goes to find the DA, it binds a udp port to
unspecified, unused port, and sends a request to the DA-discovery
multicast address (specifically ff01::123 for v6, haven't watched v4 that=
=20
close).

Well, in slpd, both of the above sockets get the packet. The listening
code is the same for each, and is structured as "recvfrom(sock->fd, stuff,
&an_address_buffer, &pointer_to_length); do-stuff(); sendto(sock->fd,
stuff, &an_address_buffer, an_address_buffer.ss_len);". So they each
should be sending back to where the packet came from.

For the unicast address, everything works fine, and the client gets a=20
packet. For the multicast-joined address, though, things don't work. I get=
=20
an error 45 (EOPNOTSUPP) for v6 and 49 (EADDRNOTAVAIL) for v4.

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.

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

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

So what should I be doing here? Should I know that error X (different=20
depending on family) means I should try again? Should the kernel be making=
=20
this transformation for me? Should the kernel not have given me :: as a=20
peer address?

Take care,

Bill

--E5HUUwS3R9LcK7+r
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCcpmdWz+3JHUci9cRAsy1AJ995mRIoldwspSlPKgBIgcqX/iWoQCfUGr7
oTsT+dMv3YjKoTVw3nYU9Vc=
=ZZNJ
-----END PGP SIGNATURE-----

--E5HUUwS3R9LcK7+r--