From owner-freebsd-stable@freebsd.org Wed Dec 16 16:11:36 2015 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 7C6D6A48C76 for ; Wed, 16 Dec 2015 16:11:36 +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 4BA3F1E3C for ; Wed, 16 Dec 2015 16:11:35 +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 441804CF5 for ; Wed, 16 Dec 2015 17:11:33 +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 13F3C4CEE for ; Wed, 16 Dec 2015 17:11:32 +0100 (CET) Date: Wed, 16 Dec 2015 17:04:18 +0100 From: Daniel Bilik To: freebsd-stable@freebsd.org Subject: stf(4) on 10-stable Message-Id: <20151216170418.3c2ec09dfb87e9d09a026efd@neosystem.cz> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64-portbld-dragonfly4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 16 Dec 2015 16:11:36 -0000 Hi. Does anybody run recent 10-stable with working 6to4 connectivity? 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. So far, I've not found any way to force it online. Tried ifconfig down/up, ifdisabled, no_dad, and sysctl -w net.inet6.ip6.dad_count=0. The latter just makes "tentative" flag flapping. Looking at commits, I suspect that r287734 (MFC of r287094) and/or r290348 (MFC of r288600) may be responsible for this. It changed the code that handles DAD, and AFAICT at least in6if_do_dad() now returns different value for stf interfaces than before. -- Dan