From owner-freebsd-stable@freebsd.org Wed Jan 13 08:21:22 2016 Return-Path: Delivered-To: freebsd-stable@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 DE9A7A80AC0 for ; Wed, 13 Jan 2016 08:21:22 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [IPv6:2001:41d0:2:5ab8::10:15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A92881C95; Wed, 13 Jan 2016 08:21:22 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id 3ADA018DA; Wed, 13 Jan 2016 09:21:11 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from dragon.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id 5056118D1; Wed, 13 Jan 2016 09:21:10 +0100 (CET) Date: Wed, 13 Jan 2016 09:17:30 +0100 From: Daniel Bilik 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> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.29; x86_64-portbld-dragonfly4.5) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__13_Jan_2016_09_17_30_+0100_WnBeImnEEYui/8yU" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 08:21:23 -0000 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 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--