Date: Wed, 13 Jan 2016 09:17:30 +0100 From: Daniel Bilik <ddb@neosystem.org> To: freebsd-stable@freebsd.org Subject: Re: stf(4) on 10-stable Message-ID: <20160113091730.381f94e94fa5cb2b90960111@neosystem.cz> In-Reply-To: <20151216170418.3c2ec09dfb87e9d09a026efd@neosystem.cz> References: <20151216170418.3c2ec09dfb87e9d09a026efd@neosystem.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --Multipart=_Wed__13_Jan_2016_09_17_30_+0100_WnBeImnEEYui/8yU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 16 Dec 2015 17:04:18 +0100 Daniel Bilik <ddb@neosystem.org> wrote: > A week ago I upgraded two systems where stf(4) is used. They were running > 10-stable from beginning of September, with stf working fine. After > upgrade, the address on stf0 stays "tentative" indefinitely. I've finally got some time to analyze this more thoroughly. And indeed, the problem was introduced with both r287734 (changes to in6if_do_dad() in sys/netinet6/in6.c) and r290348 (changes to nd6_timer() in sys/netinet6/nd6.c), specifically in combination with stf(4) interfaces not being marked "running". Attached patch fixes that. Should I create PR for this? -- Dan --Multipart=_Wed__13_Jan_2016_09_17_30_+0100_WnBeImnEEYui/8yU Content-Type: text/x-diff; name="dad-on-stf.diff" Content-Disposition: attachment; filename="dad-on-stf.diff" Content-Transfer-Encoding: 7bit --- sys/net/if_stf.c.orig 2016-01-12 22:45:07.876281000 +0100 +++ sys/net/if_stf.c 2016-01-12 22:16:30.233678410 +0100 @@ -818,6 +818,7 @@ stf_ioctl(ifp, cmd, data) ifa->ifa_rtrequest = stf_rtrequest; ifp->if_flags |= IFF_UP; + ifp->if_drv_flags |= IFF_DRV_RUNNING; break; case SIOCADDMULTI: --- sys/netinet6/in6.c.orig 2016-01-12 22:46:09.431221000 +0100 +++ sys/netinet6/in6.c 2016-01-12 22:11:22.173685329 +0100 @@ -2375,6 +2375,7 @@ in6if_do_dad(struct ifnet *ifp) case IFT_DUMMY: #endif case IFT_FAITH: + case IFT_STF: /* * These interfaces do not have the IFF_LOOPBACK flag, * but loop packets back. We do not have to do DAD on such --Multipart=_Wed__13_Jan_2016_09_17_30_+0100_WnBeImnEEYui/8yU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160113091730.381f94e94fa5cb2b90960111>