[vbox-dev] tuntap hacks for FreeBSD vbox hosts (bandaid till vbox-net driver...)

[Mario Lobo]

On Thursday 20 August 2009 13:46:19 Juergen Lock wrote:
> In article <200908200121.49710.mlobo at digiart.art.br> you write:
> >On Wednesday 19 August 2009 16:34:48 Juergen Lock wrote:
> >> [Resent with proper From, sorry forgot this list is subscribed-only...]
> >>
> >> ----- Forwarded message from Juergen Lock <nox at jelal.kn-bremen.de> -----
> >>
> >> Date: Wed, 19 Aug 2009 20:54:48 +0200
> >> From: Juergen Lock <nox at jelal.kn-bremen.de>
> >> To: vbox-dev at virtualbox.org
> >> Cc: freebsd-emulation at FreeBSD.org
> >> Subject: tuntap hacks for FreeBSD vbox hosts (bandaid till vbox-net
> >> 	driver...)
> >> User-Agent: Mutt/1.5.20 (2009-06-14)
> >>
> >> Hi!
> >>
> >>  After inquiring on the #vbox-dev channel whether the tuntap code could
> >> be resurrected for hosts that don't have vbox net/bridge drivers yet
> >> (like FreeBSD :) I now got it working - except the config gui and
> >> ifup/down scripts, the code for at least the latter seems to have been
> >> ripped out for good indeed...  So for now you have to use VBoxManage
> >> something like this,
> >> 	VBoxManage modifyvm <VM name> --nic1 bridged --bridgeadapter1 tap0
> >> and manually configure your tap interface and (optionally) add it to a
> >> bridge before the VM starts.  If you already have setup your host system
> >> to use tuntap networking with qemu you probably can just chown/chmod
> >> /dev/tap0 (or whichever one you use) to 660 root:vboxusers and then run
> >> your /usr/local/etc/qemu-ifup script with the same tap interface as arg,
> >> otherwise do something like...
> >> 	kldload if_tap if_bridge
> >> 	sysctl net.link.tap.user_open=1
> >> 	chown root:vboxusers /dev/tap0
> >> 	chmod 660 /dev/tap0
> >> 	ifconfig bridge0 create
> >> 	ifconfig bridge0 addm <host physical interface>
> >> 	ifconfig tap0 <ip> netmask <netmask>
> >> 	ifconfig bridge0 addm tap0
> >> and then start the guest.  (You'll have to rerun the `ifconfig tap0 ...'
> >> each time before you start the guest again.)
> >>
> >>  Tested on the stable/8 FreeBSD branch with the vbox version currently
> >> in ports.  (which btw today seems to have hit the same FreeBSD vboxdrv
> >> bug with svm and npt here while scp'ing a big file out of a guest that
> >> I previously thought only plagued intel vt-x users, see this post for
> >> details...
> >> 	http://lists.freebsd.org/pipermail/freebsd-emulation/2009-August/006692
> >>.ht ml )
> >>
> >>  Anyway, here comes the patch, enjoy! :)
> >>[...]
> >
> >WoW !! Tested and it works beautifully !!!!
> >
> >You're the man, Juergen !!
>
> Thanx, I'm glad it works for you.
>
> >I have set up the proper patch-*.* files for the port's /files directory.
> >Please let me know if you want them.
>
>  Oh I just put it in files/ as one single patch file here since it
> adds one feature, also that way it'll be easier to remove once it
> (or something equivalent) is committed upstream later.
>

Indeed! I'll do the same. By the way, I used virtualbox-3.0.51r22226.tar.bz2 
for this.

>
>  You're welcome! :)
> 	Juergen

I found one catch.

When I tested at home, I had the following set up:
(I am omitting the tap0 line, which is auto-added to the bridge when created.
autobridge_bridge0="re0 tap0 tap1 tap2 ... tapn")

re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 
1500
        ether 00:1a:92:91:29:d4
        inet 10.10.10.2 netmask 0xffffff00 broadcast 10.10.10.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether a6:f1:36:fc:30:fc
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: re0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 1 priority 128 path cost 200000

which worked fine, as reported.


But at work (because of openVpn tests), the bridge had the IP:

bge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 
1500
        ether 00:2a:44:77:09:12
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether a6:f1:36:fc:30:fc
        inet 172.16.3.12 netmask 0xffffff00 broadcast 172.16.3.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: bge0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 1 priority 128 path cost 200000

which caused the VM to abort every time it started the network subsystem 
(windows XP). Don't know if or why this is the cause, but as soon as I moved 
the IP to the NIC, it worked fine (either DHCP or fixed IP)!

I red somewhere that we should not assign an IP to a bridge, but I must say 
that up to now, I had this at work for a long time and it worked with 
absolutely everything.

-- 
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE)