How do I create a wifi network bridge with qemu on OS X?
I grabbed a small FreeBSD live CD and QEMU, and I'm trying to bridge my Mac OS X 10.8 wifi connection so that the guest OS is available on my LAN. However, the guest OS never gets a DHCP lease.
This works perfectly with VirtualBox in their "bridged" network mode, so I know it can be done. I need to get it working with QEMU because VirtualBox doesn't support the architecture that I need for this project.
Here's what I've done so far based on hours of googling:
Installed TUNTAP for OS X
-
Told OS X to supposedly forward all packets, even ARP: (NOTE: This doesn't appear to work.)
$ sudo sysctl -w net.inet.ip.forwarding=1 $ sudo sysctl -w net.link.ether.inet.proxyall=1 $ sudo sysctl -w net.inet.ip.fw.enable=1
-
Created a bridge:
$ sudo ifconfig bridge0 create $ sudo ifconfig bridge0 addm en0 addm tap0 $ sudo ifconfig bridge0 up $ ifconfig bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether ac:de:xx:xx:xx:xx Configuration: priority 0 hellotime 0 fwddelay 0 maxage 0 ipfilter disabled flags 0x2 member: en0 flags=3<LEARNING,DISCOVER> port 4 priority 0 path cost 0 member: tap0 flags=3<LEARNING,DISCOVER> port 8 priority 0 path cost 0 tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 ether ca:3d:xx:xx:xx:xx open (pid 88244)
-
Started
tcpdump
with-I
in the hopes that it enables promiscuous mode on the wifi device:$ sudo tcpdump -In -i en0
-
Run QEMU using the bridged network instructions:
$ qemu-system-x86_64 -cdrom mfsbsd-9.2-RELEASE-amd64.iso -m 1024 \ -boot d -net nic -net tap,ifname=tap0,script=no,downscript=no
But the guest system never gets a DHCP lease:
If I tcpdump -ni tap0
, I see lots of traffic from the wireless network. But if I tcpdump -ni en0
, I don't see any DHCP traffic from the QEMU guest OS.
Any ideas?
Update 1: I tried sudo defaults write "/Library/Preferences/SystemConfiguration/com.apple.Boot" "Kernel Flags" "net.inet.ip.scopedroute=0"
and rebooting per this mailing list suggestion, but this didn't help. In fact, it made VirtualBox bridged mode stop working.
Update 2: Interestingly, the virtual interface on the QEMU guest only gets broadcast packets. Maybe I need to add a route somehow? Hmm...
Try this when you create a bridge:
sudo ifconfig en0 down ####Shut Down the interface #####
sudo ifconfig en0 inet delete ####To clean out the old sys hooks. Don't worry you did uninstall the driver ##### Then:
sudo ifconfig bridge0 create
$ sudo ifconfig bridge0 addm en0 addm tap0
$ sudo ifconfig bridge0 up
I went through this with GNS3 and a Riverbed Steelhead Lab So I have experienced this myself.
This will bring your bridge up.
As you pointed out, VM software such as VirtualBox does have ways of bridging to a Wi-Fi interface. However, this is apparently hard to do, and is not the same thing that ifconfig does. As far as I understand, ifconfig performs ethernet bridging, i.e., it can bridge only combinations of real ethernet interfaces or virtual "TAP" ethernet interfaces. So this includes bridging two TAP interfaces. I don't know about TUN interfaces.
The issue you're having with QEMU is one I solved recently with the Macintosh emulators SheepShaver and Basilisk II, which also can load their own TAP interface provided by TunTapOSX. What I did was set up a bridge-mode OpenVPN server in a Linux VM on a separate computer, which takes some work, but is an extremely useful tool. Then, if you're on the same LAN as the VPN server, you can connect to it via the server's private IP address. I note this in my guide, linked below. Follow the first guide for setting up the OpenVPN server, and the second guide for getting the emulator connected.
http://www.emaculation.com/doku.php/bridged_openvpn_server_setup http://www.emaculation.com/doku.php/wireless_appletalk_ss_bii_osx
The catch is that the computer running the OpenVPN server must be connected to the router by ethernet. Also note that that computer cannot be running an emulator using ethernet bridging since this may interfere with the bridging required in the Linux VM for OpenVPN, or vice versa.