From owner-freebsd-emulation@FreeBSD.ORG Thu Jan 7 19:04:00 2010 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBCA11065692 for ; Thu, 7 Jan 2010 19:04:00 +0000 (UTC) (envelope-from vbox-devel-l@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 7530D8FC15 for ; Thu, 7 Jan 2010 19:04:00 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id E132B1E00760; Thu, 7 Jan 2010 20:03:58 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o07Iw8WS016746; Thu, 7 Jan 2010 19:58:08 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o07Iw8P0016745; Thu, 7 Jan 2010 19:58:08 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Thu, 7 Jan 2010 19:58:08 +0100 To: freebsd-emulation@FreeBSD.org Message-ID: <20100107185808.GA16577@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: vbox-dev@virtualbox.org Subject: vbox (and qemu) tap/vboxnetflt networking; bridging vs wifi X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 19:04:01 -0000 Hi! As noted earlier on freebsd-emulation, wifi users have a problem when they want to expose a VM guest on their lan: simply bridging it to the wifi interface usually doesn't work because hosts on wifi can only use a single mac address. As I now found out, vbox on (at least) Linux/Windows hosts attempts to work around this issue by implementing a shared mac feature that gets enabled if you use bridged mode on a wifi nic there, so I tried enabling that for FreeBSD hosts too: http://people.freebsd.org/~nox/vbox/patch-sharedmac.txt (patches are under MIT license and for vbox 3.1.2 as featured in the recent ports CFT, I haven't checked if they also apply to the older version still in ports) - and Beat tested that yesterday since I don't have wifi here myself, he couldn't get it working properly. Maybe the FreeBSD vboxnetflt code needs to be adjusted for this too? But... I also made another patch to make vbox dtrt when you use bridged mode with a tap interface, http://people.freebsd.org/~nox/vbox/patch-tapdirect.txt and he tested using that to do routing + proxy arp for the guest IP, and _that_ worked. :) (As mentioned before in other -emulation threads, tap can also be used with if_bridge to do basically the same thing as vbox' bridged mode (vboxnetflt) now does via netgraph, I won't cover that here again - see e.g. my original vbox tap thread for an example: http://lists.freebsd.org/pipermail/freebsd-emulation/2009-August/006693.html btw you can select the tap interface in the GUI now if it is configured so you don't need VBoxManage for that anymore.) Anyway, here goes the routing example: kldload if_tap sysctl net.link.tap.user_open=1 sysctl net.link.ether.inet.proxyall=1 sysctl net.inet.ip.forwarding=1 chown root:vboxusers /dev/tap0 chmod 660 /dev/tap0 ifconfig tap0 netmask The tap0 (and guest) IPs here need to be in a sub-subnet of your host's physical network (the wifi interface's in this case), and the usual cidr subnetting rules apply, i.e. since you need two IPs in the subnet (tap0 and guest) and you want to avoid IPs with all of the lower bits set or cleared you need at least a /30, i.e. netmask 0xfffffffc. (You should also be able to use if_bridge to bridge multiple guest's tap interfaces together in which case only the bridge interface needs an IP, but then of course you need a larger subnet.) So, assuming your network is 192.168.0/24 (and you have no other hosts in the following subnet) you can try: ifconfig tap0 192.168.0.17 netmask 0xfffffffc and in the guest configure the emulated nic as 192.168.0.18 with the same netmask and the tap interface IP as gateway. dns then can be the same as the host uses (see /etc/resolv.conf) and that's it, the guest should have network and be reachable from the lan as 192.168.0.18. The only downside of doing it this way is the tap interface loses its IP when vbox closes it and the ifup/down script feature has been removed from vbox so you need to rerun the `ifconfig tap0 ...' each time before you start the guest again. (Maybe that can be avoided if you set net.link.tap.up_on_open=1, put only the tap interface on an if_bridge and give that bridge interface the IP instead, I haven't tried.) Oh and btw, direct tap networking like this also still seems to perform better than the current FreeBSD vboxnetflt implementation, so if guest network performance is important... And doing it the routing way instead of bridging also protects from guests messing with your lan's arp tables, altho in that case you probably shouldn't set net.link.ether.inet.proxyall but setup specific proxy arp entries only for your guest(s) IP(s). [1] And finally, the same applies to qemu, only there you can of course still put the `ifconfig tap0 ...' in /usr/local/etc/qemu-ifup (using sudo unless you run qemu as root.) Cheers, Juergen [1] The details of this depend on your host's FreeBSD version, on 7.x and before you can do: arp -s auto pub only before(!) configuring the tap interface, while on 8.x and -current this doesn't work anymore because of the new routing code, but there this instead seems to work: arp -s auto pub - also before configuring the tap interface. And note this arp entry gets deleted along with the tap interface's route when vbox closes it so you need to rerun that command each time before you start the guest again too.