"Alexander V. Chernikov" <melif...@freebsd.org> wrote in <4ffa9723.5000...@freebsd.org>:
me> On 09.07.2012 12:08, Hiroki Sato wrote: me> > "Alexander V. Chernikov"<melif...@freebsd.org> wrote me> > in<4ffa894d.9050...@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
pgp6BTQLuYxbh.pgp
Description: PGP signature
