From owner-freebsd-net@freebsd.org Mon Nov 6 04:22:56 2017 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 AE3CBE59292 for ; Mon, 6 Nov 2017 04:22:56 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (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 7903177C86 for ; Mon, 6 Nov 2017 04:22:56 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AABC07A330E; Mon, 6 Nov 2017 04:22:48 +0000 (UTC) Date: Mon, 6 Nov 2017 04:22:48 +0000 From: Viktor Dukhovni To: freebsd-net@freebsd.org Subject: [PATCH]: The 6to4 stf0 interface flapping in/out of tentative in FreeBSD 11 Message-ID: <20171106042248.GL3322@mournblade.imrryr.org> Reply-To: freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailer: Apple Mail (2.3445.4.7) User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 04:22:56 -0000 Some time ago I wrote: > On Mar 4, 2017, at 9:05 PM, Viktor Dukhovni wrote: > > In trying to set up a 6to4 node under 11.0-RELEASE-p8, and the stf0 > interface is constantly flipping in and out of "tentative" state, at > seemingly 1 second intervals. Is that to be expected? Am I missing > some non-obvious configuration setting? Today, I looked closely at the kernel sources and found the issue. Patch below. Interfaces found to not have IFF_DRV_RUNNING in if_drv_flags by the periodic interface scan are marked tentative. Since the "stf" driver did not set that flag, the "stf" interface flaps. Index: sys/net/if_stf.c =================================================================== --- sys/net/if_stf.c (revision 325169) +++ sys/net/if_stf.c (working copy) @@ -722,6 +722,7 @@ } ifp->if_flags |= IFF_UP; + ifp->if_drv_flags |= IFF_DRV_RUNNING; break; case SIOCADDMULTI: While I was at it, I also changed the below because for "stf" the only effect of "break" was the misleading logging: stf0 is not multicast caple, IPv6 not enabled Perhaps there is some configuration I am not taking into account in which something more useful happens... Feeback appreciated. Index: sys/netinet6/in6_ifattach.c =================================================================== --- sys/netinet6/in6_ifattach.c (revision 325169) +++ sys/netinet6/in6_ifattach.c (working copy) @@ -696,25 +696,25 @@ /* * quirks based on interface type */ switch (ifp->if_type) { case IFT_STF: /* * 6to4 interface is a very special kind of beast. * no multicast, no linklocal. RFC2529 specifies how to make * linklocals for 6to4 interface, but there's no use and * it is rather harmful to have one. */ ND_IFINFO(ifp)->flags &= ~ND6_IFF_AUTO_LINKLOCAL; - break; + return; default: break; } /* * usually, we require multicast capability to the interface */ if ((ifp->if_flags & IFF_MULTICAST) == 0) { nd6log((LOG_INFO, "in6_ifattach: " "%s is not multicast capable, IPv6 not enabled\n", if_name(ifp))); return; -- Viktor.