Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Jul 2012 05:30:02 +0900 (JST)
From:      Hiroki Sato <hrs@FreeBSD.org>
To:        melifaro@FreeBSD.org, net@FreeBSD.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
Message-ID:  <20120710.053002.914215153752773154.hrs@allbsd.org>
In-Reply-To: <4FFA9723.5000301@FreeBSD.org>
References:  <4FFA894D.9050104@FreeBSD.org> <20120709.170813.339720376082380726.hrs@allbsd.org> <4FFA9723.5000301@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Tue_Jul_10_05_30_02_2012_869)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Alexander V. Chernikov" <melifaro@FreeBSD.org> wrote
  in <4FFA9723.5000301@FreeBSD.org>:

me> On 09.07.2012 12:08, Hiroki Sato wrote:
me> > "Alexander V. Chernikov"<melifaro@FreeBSD.org>  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)----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120710.053002.914215153752773154.hrs>