[vbox-dev] Using VirtualBox network drivers

Gary Palter palter at clozure.com
Thu Aug 8 11:16:51 PDT 2013

Hi Klaus,

Thanks for the explanation.

I had already implemented networking for our emulator using Linux bridging.  But, in my testing, it seemed to stop working after a few minutes.  And my client was never able to configure his system successfully.

Nevertheless, I'm now recommending to my client that we try the bridging route again.

Thanks again for your advice,

  - Gary Palter
    Principal Software Engineer
    Clozure Associates
    Cell:  617-947-0536

On Aug 8, 2013, at 1:50 PM, Klaus Espenlaub <klaus.espenlaub at oracle.com> wrote:

> Hi Gary,
> On 08.08.2013 18:30, Gary Palter wrote:
>> On Jul 18, 2013, at 12:04 PM, Klaus Espenlaub <klaus.espenlaub at oracle.com> wrote:
>>> Hi Gary,
>>> On 18.07.2013 17:11, Gary Palter wrote:
>>>> Well, I'm back.
>>>> My client has informed me that the alternatives suggested below aren't
>>>> acceptable.  They want to use the VirtualBox network drivers.  How can I
>>>> use those drivers without creating a VirtualBox VM?  Any pointers to
>>>> documentation or sample code that will show me what I need would be most
>>>> helpful.
>>> See src/VBox/Drivers/Network/Drv{UDPTunnel,VDE}.cpp - these are the
>>> already existing samples.
>>> There's no standalone SDK for this, so right now there's no pre-canned
>>> way of building such drivers outside a VirtualBox build.
>>> Klaus
>> I don't think you understood my question.  Let me explain exactly what I need to do.
>> The software that runs in the emulator I'm writing needs access to the network.  The operating system that runs on the emulator is very old and requires static IP addresses.  (It has no DHCP client.)  If I were creating a VirtualBox VM, I would add a bridged network with a static IP to that VM.  But, this is an emulator for an entirely different architecture; I can't use a VirtualBox VM.
> OK, I really misunderstood then. You want to reuse the host driver bits in a totally separate project.
> This is actually very difficult, as both vboxnetflt and vboxnetadp are built on top of the vbox kernel "machinery", which means that they interface to the vbox virtual switch implementation in the kernel (in SrvIntNetR0.cpp) through generic communication mechanisms implemented in vboxdrv. Effectively you'd drag in a big portion of VirtualBox, pretty much all the complicated kernel bits.
> Not sure if this is worth the effort for your project...
> This ignores the fact that a hardened VirtualBox build (the default for releases) does not accept any unexpected clients to vboxdrv for security reasons.
>> What I want to do is use the existing VirtualBox network drivers (vboxnetflt, I think) in my emulator.  I want to open that driver, configure it (i.e., tell it what host interface to use, MAC address, IP address, etc), and the transmit and receive packets using the driver.
> I wonder if using Linux bridging and tap interfaces wouldn't be the better solution for your project, as it'd cleanly separate it from VirtualBox. Both can easily coexist (of course internal networking will be out of reach for your project, but this is very special anyway).
> Note that this suggestion causes quite some pain for me, remembering the hell we faced when VirtualBox used this approach, too. It never worked truly reliably, there was always a system/config out there which couldn't get proper network connectivity this way, sometimes intermittent or after a long time of perfect operation. Maybe we were just not capable enough, other people supposedly used this successfully in many places (it originates in the UML project, user mode linux), e.g. OpenVPN in ethernet bridging mode.
> The beauty of this solution is that it doesn't require any non-standard kernel components.
> Klaus
>> Can anyone offer suggestions?
>> Thanks again,
>>   - Gary
>>>> Thank you,
>>>>   - Gary Palter
>>>>     Principal Software Engineer
>>>>     Clozure Associates
>>>> On Dec 5, 2012, at 6:59 PM, Ivo Smits <Ivo at UFO-Net.nl
>>>> <mailto:Ivo at UFO-Net.nl>> wrote:
>>>>> Just a few ideas which are probably somewhat easier:
>>>>> - Use libpcap to capture and inject network packets (useable directly
>>>>> from userspace, you will need to handle packet filtering yourself but
>>>>> it's easy)
>>>>> - Use a tap device and a linux kernel network bridge (the tap device
>>>>> will work like a real switch port, with some filtering provided by the
>>>>> network bridge)
>>>>> - Use VDE (should be easy to use, can connect to host network
>>>>> interfaces, tap devices or act as a NAT gateway)
>>>>> Ivo Smits
>>>>> Op 5-12-2012 23:17, Gary Palter schreef:
>>>>>> I am working on a project for a client which involves migrating a 20+
>>>>>> year old application to Linux.  (All I can say about the application
>>>>>> is that it's an emulator for an almost 30 year old computer
>>>>>> architecture.)
>>>>>> The guest's operating system is aware that it's running in a virtual
>>>>>> machine.  For network access, it communicates with the emulator
>>>>>> through a set of queues to send and receive Ethernet packets.  In the
>>>>>> original emulator, we attach a packet filter to the Ethernet
>>>>>> interface in order to inject packets onto the wire and grab packets
>>>>>> intended for the guest.
>>>>>> For the new emulator, we want to use the VirtualBox network drivers
>>>>>> to setup a bridged interface.  I've spent several hours reading
>>>>>> through the source code and, frankly, I'm lost.
>>>>>> How, exactly, does VirtualBox setup a bridged interface?  (I know
>>>>>> that VboxNetFlt driver is involved but I don't know how it's hooked
>>>>>> up.)  How is ARP handled?  How would I use the VirtualBox drivers in
>>>>>> our emulator, keeping in mind that there's no VBox guest involved?
>>>>>> Thank you for your assistance,
>>>>>> - Gary Palter
>>>>>>   Principal Software Engineer
>>>>>>   Clozure Associates

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130808/a71d200a/attachment.html 

More information about the vbox-dev mailing list