Re: IPv6 problems.... (dhcpcd weirdness, rshd fails, etc.)

You got the address somehow, and the way you got it almost certainly =
told you which interface to use. Making the kernel send an arbitrary =
number of ND multicasts (one per interface) to figure this out =
automatically would be .. not ideal. Both in terms of the complexity it =
would add to the kernel, and in terms of the cost it would impose on the =
network.

> On 19 Nov 2025, at 03:23, Greg A. Woods <[email protected]> wrote:
>=20
> At Tue, 18 Nov 2025 10:42:41 +0100, Ted Lemon <[email protected]> =
wrote:
> Subject: Re: IPv6 problems.... (dhcpcd weirdness, rshd fails, etc.)
>>=20
>> On 18 Nov 2025, at 10:39, Ted Lemon <[email protected]> wrote:
>>>=20
>>> if (IN6_IS_ADDR_LINKLOCAL(&sa1->sin6_addr)) {
>>=20
>> This is what I get for sending code I'm in the middle of writing:
>> the above doesn't make sense in context. The code snippet should
>> actually be:
>>=20
>>                server->server_address.sa.sa_family =3D AF_INET6;
>>                server->server_address.sin6.sin6_addr =3D
>>                response->rr.data.aaaa;
>>                if
>>                    =
(IN6_IS_ADDR_LINKLOCAL(&server->server_address.sin6_addr))
>>                    { server->server_address.sin6.sin6_scope_id =3D
>>                    response->interface_index;
>>                }
>>=20
>=20
> Hmmm....  I think that gives me a better idea of what to look for, =
thanks!
>=20
> So the following compiles, but I don't know yet if it fixes the =
problem
> and won't be able to test for a bit:
>=20
> --- lib/libc/netrcmd.c.~1.71.~	2015-02-19 20:58:57.000000000 =
-0800
> +++ lib/libc/netrcmd.c	2025-11-18 18:03:06.845451361 -0800
> @@ -542,9 +542,12 @@
> 		sa->sa_len =3D
> #endif
> 		salen =3D sizeof(struct sockaddr_in6);
> -		if (addr)
> +		if (addr) {
> 			((struct sockaddr_in6 *)(void *)sa)->sin6_addr =3D=

> 			    ((struct sockaddr_in6 *)addr)->sin6_addr;
> +			((struct sockaddr_in6 *)(void =
*)sa)->sin6_scope_id =3D
> +			    ((struct sockaddr_in6 =
*)addr)->sin6_scope_id;
> +		}
> 		portp =3D &((struct sockaddr_in6 *)(void =
*)sa)->sin6_port;
> 		break;
> #endif
>=20
>=20
> But maybe the sin6_scope_id field gets lost earlier (too?)?
>=20
> It seems silly to me that the kernel can't figure this out itself when
> it knows the address explicitly and completely as it does in this =
case.
> I'm pretty sure you can't have the same address on two different
> interfaces no matter what family they belong to.  The log message
> showing the incoming connection even shows the interface name.
>=20
>>> Nov 15 21:17:32 once inetd[10044]: connection from =
fe80::1030:c7e5:ac6d:b5ce%bge0(fe80::1030:c7e5:ac6d:b5ce%bge0), service =
shell (tcp6)
>>> Nov 15 21:17:32 once rshd[10044]: can't get stderr port: Can't =
assign requested address
>=20
> I see there's also inet6_getscopeid(3) that seems to just look in the
> address to get the id.
>=20
> --
> 					Greg A. Woods <[email protected]>
>=20
> Kelowna, BC     +1 250 762-7675           RoboHack <[email protected]>
> Planix, Inc. <[email protected]>     Avoncote Farms <[email protected]>