From owner-freebsd-stable@freebsd.org Mon Sep 24 13:51:28 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85C1510ACBC4 for ; Mon, 24 Sep 2018 13:51:28 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 060DF8178F for ; Mon, 24 Sep 2018 13:51:27 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from localhost ([92.134.114.191]) by mwinf5d56 with ME id fRrR1y01B47q9Nc03RrSsW; Mon, 24 Sep 2018 15:51:26 +0200 X-ME-Helo: localhost X-ME-Auth: Y2xidWlzc29uQHdhbmFkb28uZnI= X-ME-Date: Mon, 24 Sep 2018 15:51:26 +0200 X-ME-IP: 92.134.114.191 To: FreeBSD-STABLE Mailing List , oshogbo@FreeBSD.org From: Claude Buisson Subject: traceroute -n difference between STABLE-11 and CURRENT Message-ID: <4c75a92e-e107-9a77-aff5-fd914c7527b9@orange.fr> Date: Mon, 24 Sep 2018 15:51:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 13:51:28 -0000 Hello, On systems with STABLE-11 @ r338696, I found that traceroute -n ... led to: traceroute: cap_enter: Function not implemented I rebuilt the systems with WITHOUT_CASPER commented in /etc/src.conf and (to be safe ?) CAPABILITY_MODE CAPABILITIES uncommented in the kernel definitions And traceroute -n can now be successfully used. Being curious, I traced this behaviour to r338475 by oshogbo, which is documented as a MFC of r314000 BUT i NEVER met this problem on my CURRENT systems which are now at r338331 (so after r314000), and are built WITHOUT_CASPER and without CAPABILITY_MODE nor CAPABILITIES in their kernel definitions. What am I missing (my only hint being the change from HAVE_LIBCASPER to WITH_CASPER) ? CBu