From owner-svn-src-all@FreeBSD.ORG Mon Jul 9 20:30:31 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00982106566B; Mon, 9 Jul 2012 20:30:31 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 4926E8FC08; Mon, 9 Jul 2012 20:30:30 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q69KUBMe014546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 05:30:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q69KUAf4075857; Tue, 10 Jul 2012 05:30:11 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 10 Jul 2012 05:30:02 +0900 (JST) Message-Id: <20120710.053002.914215153752773154.hrs@allbsd.org> To: melifaro@FreeBSD.org, net@FreeBSD.org From: Hiroki Sato In-Reply-To: <4FFA9723.5000301@FreeBSD.org> References: <4FFA894D.9050104@FreeBSD.org> <20120709.170813.339720376082380726.hrs@allbsd.org> <4FFA9723.5000301@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Jul_10_05_30_02_2012_869)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 10 Jul 2012 05:30:22 +0900 (JST) X-Spam-Status: No, score=-96.8 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r238277 - in head: etc/defaults etc/rc.d sbin/ipfw share/man/man5 sys/netinet/ipfw X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: net@FreeBSD.org List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:30:31 -0000 ----Security_Multipart(Tue_Jul_10_05_30_02_2012_869)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Alexander V. Chernikov" wrote in <4FFA9723.5000301@FreeBSD.org>: me> On 09.07.2012 12:08, Hiroki Sato wrote: me> > "Alexander V. Chernikov" wrote me> > in<4FFA894D.9050104@FreeBSD.org>: me> > me> > I meant there was no strong objection. I am sorry for not commenting me> > your implementation, but at least for ipfw0 it is difficult to me> > decouple ifnet and bpf because the primary consumer is tcpdump(8), me> > which depends on NET_RT_IFLIST to find the target. Probably your me> tcpdump -i still works with interface name supplied. me> > solution can be used for usbdump(8). The reason why I committed the me> > patch now is there are reports that these pseudo interfaces made some me> > applications confused and/or caused some performance degradation on me> > 9.0R, and wanted to fix it in some way. me> Do you plan to take this to 9.1 ? Originally I thought of it but I think it was too late. It should be polished in -CURRENT for a while also in terms of how to hide the interfaces. me> > I am still open for more sophisticated implementation and have no me> > objection to replace mine with it. Do you have an idea about me> > converting it with a loadable module? me> Personally I think that the right way is to add user<>kernel interface me> for requesting interface list since this is the most major stopper for me> doing BPF-only providers. However this should be discussed with me> rpaulo@ and delphij@ (so most probably this skips 9.1). Adding a sysctl to list all of the struct bpf_if including ones with a fake ifp? Hm, my goal was just to hide usbusN and ipfw0 *by default* but there was no problem with having ipfw0 with an ifnet. I thought having ifnet was tolerable if its consumer was tcpdump-like one because there are a lot of packet dump utilities which obtain interface names from the system's network interface list. Hiding the interface is rather confusing from user's perspective. I do not stick to the committed code and have no objection about adding a new API if it is useful. Well, please let me check if I understand your idea correctly. Given that we add a new API to enumerate the interfaces including bpf-only providers with fake ifnets, which providers/utilities should be converted to use it? IMO usbusN would be a reasonable target but others still need a real ifnet. In my understanding, the advantage of using a fake ifnet is just to prevent it from appearing as an interface. Is it correct? me> And, as fallback solution we can probably add separate ipfwlog module me> which is quite easy but much less clean. I think whether having it as a kernel module or not is orthogonal to hiding the interface. If we support multiple instances of the pseudo interface (typical in a system with vnet), cloning capability is needed in any way. -- Hiroki ----Security_Multipart(Tue_Jul_10_05_30_02_2012_869)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/7P0oACgkQTyzT2CeTzy3nFgCgi4rHRHX7M2iRk+1Fex+xjvuY uzQAnRZ5OgQKnlB+CkF2fnZOYae/SuVF =oK8F -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Jul_10_05_30_02_2012_869)----