VirtualBox bridged adapter (vboxnetflt)

[Fredrik Lindberg]

Robert Watson wrote:
> 
> On Fri, 21 Aug 2009, Fredrik Lindberg wrote:
> 
>> I've started working on the missing bits of the FreeBSD network 
>> implementation in VirtualBox.
>>
>> I now have a working vboxnetflt.ko driver that allows automatic 
>> bridged networking in VirtualBox (probably what most people want). 
>> This allows guests to automatically bridge with your existing network 
>> adapter providing seamless network access.
>>
>> Work on host-only adapter mode is in progress (this should not be 
>> confused with host-interface in previous vbox 2.x releases).
> 
> Hi Fredrik:
> 
> The technical approach you've taken here is a bit unusual and 
> potentially quite fragile -- replacing the method pointers on struct 
> ifnet's maintained by other drivers and "borrowing" spare fields is 
> likely going to prove problematic in the future (and, in fact, already).
> 
> It looks like a lot of what the driver is trying to accomplish can 
> already be done entirely from userspace using bpf(4): taking a tee of 
> incoming frames arriving at the NIC, perhaps selecting down to ones to 
> specific ethernet addresses, taking the card into and out of promiscuous 
> mode, and injecting frames into the output path, are exactly what BPF is 
> designed to support.  I was wondering if you'd looked at this approach 
> as an alternative to a custom kernel driver?
> 
> Robert
> 

That's why I ended my mail by saying it's "hackish" (which usually mean
fragile) :)

vboxnetflt is a driver that exists for all operating systems
capable of running in virtualbox host mode. It consists of both
operating system independent code and operating system dependent code.
This together forms a kernel module (on all host OS) which in turn
depend on symbols in the other kernel support driver (vboxdrv.ko).

So, unless we re-write a lot of the generic code in VBox, this
have to be done in the kernel (disclaimer, I haven't really
looked on what would have to be changed, but it's not very
attractive to start messing with their generic code).

I've actually looked at BPF..but didn't find a clean API from the
kernel (maybe I just don't know where to look). (Opening /dev/bpf
from the kernel seemed just as fragile as the current approach if it's 
even possible).

The third approach is to add vbox glue to ifnet and ether_output,
but that is just as bad (accounting for third party software in
the kernel is just ugly).

At least Darwin seems to have a "filtering" mechanism that allows
you to manipulate mbufs before they are sent to the interface.
Linux seems to have a similar mechanism, but not as flexible as
the one in Darwin.

I was thinking along the same lines for FreeBSD. Implementing generic
hooks in the input/output path that could be used for vbox, if_bridge,
carp, etc, instead of the current hard coded calls in
ether_{output,input}. This could also have the effect of removing module 
specific glue from struct ifnet.
Anything worth pursuing ?

Fredrik Lindberg