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

On Fri, Apr 29, 2005 at 07:58:13PM -0400, Greg Troxel wrote:
>   My confusion is that I received a request on socket X and grabbed the p=
eer=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 grou=
p)=20
>   with what seems like the exact same addresses, it works.
>=20
> I don't see a need to have two sockets.  Are you checking all the
> syscall returns, in particular the second bind (SO_REUSEADDR?)?

It's actually using SO_REUSEPORT. And with v6 and default routes for=20
ff02::/16 and ff05::/16, there are also link- and site-local scopes.

> Try with just one socket.

That's a separate aspect of the design.

The multicast socket is supposed to get all node-scope packets.

The other socket is, in principle, supposed to get all unicast packets. I=
=20
think; I didn't write this code.

I'm not 100% sure that unicast is needed, but I'm not ready to change that
just yet. Its precence could also be a reflection of this other part not
working...  :-)

>   No... Sorry. That's I have the "multicast" socket bound to address=20
>   unspecified, port 427, which has joined the right multicast group.
>=20
> This is redundant with the socket bound to unspecified/427 and not
> joined.

You can configure which addresses slpd uses for listening. The=20
non-multicast socket represents that one. I haven't specified any=20
interfaces, so it's using "::". If I'd specified interfaces, it'd be one=20
of the external interfaces. So maybe the thing to do is skip the=20
node-local addresses if we are unbound.

As a separate note, it could be that slpd will need to change its socket=20
behavior if it has a list of addresses or not.

>   I agree it seems broken. Does transmitting a packet over loopback set t=
he=20
>   "sender" address to that of loopback?
>=20
> <asbestos>Well, I suppose it probably depends if you have a strong ES
> or a weak ES.</> But yes, on normal NetBSD, if the packet is from a
> socket on the same host, and lo0 is selected since you are
> transmitting to localhost, the source address should end up 127.0.0.1,
> and that should show up in recvfrom as 127.0.0.1.  But that's quite
> distinct from 0.0.0.0, which makes no sense as a source address.

Yes, as the other note indicates, it is showing up with a real address=20
(either ::1 for v6 or 10.0.0.6 for v4)

>   I'll double-check I didn't bork something else and that my printfs are=
=20
>   right...
>=20
> Watch out for static buffers in inet_ntoa and using the function twice
> in one printf.

Oh, yeah, that was it...

So I looked closer, and found that the statistics are telling me what the=
=20
kernel thinks is wrong. For v4, the errors stem from packets "with no=20
mbufs". ??? For v6, the errors stem from violating scope rules.

Take care,

Bill

--NgLNC/STdjXvE6Rt
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCcs86Wz+3JHUci9cRApS+AJ9P4iIXji+xfOr9haGb0XsoxGWD3QCgkpyT
mDaG7EKhSHIBn13Xx8S432Q=
=W5UR
-----END PGP SIGNATURE-----

--NgLNC/STdjXvE6Rt--