[CFT] Virtual BPF interfaces
Vadim Goncharov
vadim_nuclight at mail.ru
Mon Dec 3 15:36:57 UTC 2012
Hi Alexander V. Chernikov!
On Mon, 03 Dec 2012 16:18:38 +0400; Alexander V. Chernikov wrote about 'Re: [CFT] Virtual BPF interfaces':
> On 03.12.2012 12:11, Gleb Smirnoff wrote:
>> On Sun, Dec 02, 2012 at 04:48:18AM +0400, Alexander V. Chernikov wrote:
>> A> On 10.06.2012 18:20, Alexander V. Chernikov wrote:
>> A>> On 27.04.2012 03:44, Hiroki Sato wrote:
>> A>>> "Alexander V. Chernikov"<melifaro at FreeBSD.org> wrote
>> A>>> in<4F96E71B.9020405 at FreeBSD.org>:
>> A>>>
>> A>>> me> On 24.04.2012 21:05, Hiroki Sato wrote:
>> A>>
>> A>> Proof-of-concept patch attached.
>> A>
>> A> Hopefully, libcap code is easily extendable.
>> A> New version attached:
>> A> * BPF code is now able to use 'virtual' interfaces without real ifnet
>> A> * New bpfattach3() / bpfdetach3() routines were added to attach virtual
>> A> ifaces
>> A> * New BIOCGIFLIST ioctl is added to permit userland to retrieve
>> A> available virtual interfaces
>> A> * freebsd-specific 'platform_finddevs' version is added to libpcap code
>> A> (new file)
>> A>
>> A> There are some rough edges (conditional code in pcap-bpf.c, lack of
>> A> documentation, maybe some style issues), but generally it seems to work
>> A> and does not interfere with contrib/ code much (from my point of view).
>> A>
>> A> ipfw log device was converted to use new bpf(4) api, see attached patch.
>>
>> Nice proof of concept, Alexander!
>>
>> What does prevent us from unifing all bpf providers to be "virtual" in
>> current terms? I think if we finish divorce between ifnet and bpf, the code
>> would get simplier and you can proceed further with reducing locking
>> overhead.
> We have to jump from ifnet to the list of per-ifnet BPF consumers
> somehow, so I'm not sure if we can do much more here. BPF itself doesn't
> require much from parent ifnet.
> What I really want to do next is the following:
> 1) Make BPF_PEERS_PRESENT(ifp) to be (ifp->if_bpf != NULL). This saves
> some processing time and permits 'bpf_if' to be be totally opaque
> without any hacks.
> 2) Set if_bpf pointer IFF there are some consumers (and set it back to
> NULL when all consumers are detached). This should work well for 'main'
> BPF DLT, but single (currently, 802.11) interface can hold more than one
> DLTs. Probably we can save dst pointer passed to bpfattach2() to given
There probably will be more of them when we will support tcpdump -i iggroupnam
as admin can decide to move to one group interfaces with defferent DLTs.
> bpf_if structure, and set this value instead of ->if_bpf.
> This, however, can lead to hard-to-find problems, since bpfattach[2] is
> usually not called by driver directly.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight at mail.ru
[Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
More information about the freebsd-net
mailing list