svn commit: r238277 - in head: etc/defaults etc/rc.d sbin/ipfw share/man/man5 sys/netinet/ipfw

[Hiroki Sato]

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

me> On 09.07.2012 12:08, Hiroki Sato wrote:
me> > "Alexander V. Chernikov"<melifaro at FreeBSD.org>  wrote
me> >    in<4FFA894D.9050104 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20120709/d462aea9/attachment.pgp