From owner-freebsd-net@freebsd.org Thu Jul 2 20:11:47 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85B2A993F43 for ; Thu, 2 Jul 2015 20:11:47 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E553214F; Thu, 2 Jul 2015 20:11:47 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [IPv6:2a02:1811:2419:4e02:c060:1bf7:9ab0:74fe] (unknown [IPv6:2a02:1811:2419:4e02:c060:1bf7:9ab0:74fe]) by venus.codepro.be (Postfix) with ESMTPSA id 826ED944D; Thu, 2 Jul 2015 22:11:44 +0200 (CEST) From: Kristof Provost Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: radvd issue on CURRENT Date: Thu, 2 Jul 2015 22:12:18 +0200 Message-Id: <7B00338E-6264-44FD-9A55-8E29C01467E7@FreeBSD.org> Cc: ae@FreeBSD.org To: freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Mailman-Approved-At: Thu, 02 Jul 2015 21:19:35 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 20:11:47 -0000 Hi, In the process of setting up my TPLink device (Thanks Allan!) I ran into = problems getting radvd to work. It fails while processing the IPV6_PKTINFO options in ip6_setpktopt(). = Specifically, it fails one of the extra checks added in = r271396(https://svnweb.freebsd.org/base?view=3Drevision&revision=3D271396)= . The check 'ia =3D in6ifa_ifpwithaddr(ifp, &pktinfo->ipi6_addr);=E2=80=99 = (i.e. does the address exist on the interface?) fails, even though radvd = sets a correct address. The cause of that is that radvd picks a link-local address. Those = don=E2=80=99t match because the kernel keeps a =E2=80=98zoneid=E2=80=99 = in the link-local addresses. See for example in6_setscope(). That turns 'fe80::304d:b0ff:fe2e:9b88=E2=80=99 in userspace into = 'fe80:13::304d:b0ff:fe2e:9b88=E2=80=99 in the kernel, so the addresses = appear to be different. I=E2=80=99m a little uncertain about what the best fix for that would = be. I could mask out the =E2=80=98zoneid=E2=80=99 for link-local = addresses in in6fa_ifpwithaddr(), but that might break other things. Regards, Kristof=