VirtualBox

Opened 12 years ago

Closed 6 years ago

Last modified 6 years ago

#10019 closed defect (fixed)

Unable to bridge Mac OS X AirPort connection

Reported by: willmc Owned by:
Component: network Version: VirtualBox 4.1.6
Keywords: mac bridge wifi airport wireless network Cc:
Guest type: Linux Host type: Mac OS X

Description

If I connected my host OS (Mac OS X 10.7.2) to a Wi-Fi network, I cannot bridge the VM's network connection to that interface. The VirtualBox VM settings allow me to choose bridging over that interface, but I'm unable to obtain a DHCP lease or do anything else on that interface. Bridging to the Ethernet interface works fine, and the Wi-Fi connection works fine in the host OS.

Attachments (1)

VBox.log (64.6 KB ) - added by willmc 12 years ago.

Download all attachments as: .zip

Change History (26)

by willmc, 12 years ago

Attachment: VBox.log added

comment:1 by camjack1728, 12 years ago

I am also having this same issue. If there is any information that I can supply to help in trouble shooting this, Please let me know.

comment:2 by DrPepperAndPizza, 12 years ago

I am also having the same issue.

  • VirtualBox 4.1.18 r78361
  • Host: Mac 10.7.4. MacBook Pro. Just purchased 3 weeks ago.
  • Guest: Debian 6.0.5, CentOS 6.2. All guests really.

Bridged Network *WAS* working on Wi-Fi. But it stopped after I the the following:

  1. Created a 2nd Wi-Fi. (Directions: On Mac OS X, click "System Preferences" -> "Network" -> "+" -> Interface = "Wi-Fi", Service Name = "Wi-Fi (AirPort)" -> "Create" -> "Apply".) I created a 2nd Wi-Fi, because I was on the train going home and wanted to test a VM with 2 NICs.
  2. Create a Network. (Directions: On Mac OS X, click the wifi icon in the upper right of the screen -> "Create Network..." -> Network Name = "my network blah", Channel = 11, Security = "None" -> "Create".
  3. In Virtualbox, set the VMs to use the 2 wifi in Bridge Network mode.

Up to here, everything was working.

Here is when Bridge Networking stopped working when the wifi is used for bridged networking.

I was done testing and I deleted the 2nd Wi-fi that I created in step 1. (Directions: On Mac OS X, click "System Preferences" -> "Network" -> select "Wi-Fi (AirPort)" which was created in step 1 above -> "-" -> "Apply".

After that Bridged Networking does not work when en1: Wi-Fi (AirPort) is selected. It seems as if VirtualBox is still pointing to the one I deleted. I don't remember, but I think I named it "Wi-Fi (AirPort)". And that's the entry that VirtualBox keeps.

But "Wi-Fi" (which is the default in Mac OS X) and is the only entry in "System Preferences" -> "Network".

I tried:

  1. Deleting "Wi-Fi" and creating a "Wi-Fi (AirPort)" to match what Virtualbox is showing.
  2. Having both "Wi-Fi" and "Wi-Fi (AirPort)" entries.
  3. Uninstalling VirtualBox, reboot, then re-installing.

Nothing worked.

In the guest, Debian still cannot contact the DHCP server on my network after running /etc/init.d/networking restart: ...<snip>... Listening on LPF/eth0/08:00:27:56:00:de Sending on LPF/eth0/08:00:27:56:00:de Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 5 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 10 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 13 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 11 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 14 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 8 No DHCPOFFERS received. No working leases in persistent database - sleeping. done.

I've tail -f my dhcp logs and it shows no contact from the guest host.

I'm guessing that Virtualbox is still stuck to the 2nd wifi that I added then deleted.

Everything else works, just not Bridged Networking on wifi.

  • NAT works on both wifi and ethernet.
  • Bridged Networking works on ethernet. It used to work both both ethernet and wifi, until I added then deleted the 2nd wifi.
  • Internal Network works on both
  • Host Only Adaptor works on both, I think. Didn't really test much.

I really want and need Bridged Networking on the wifi to work. Let me know if you need any other info.

comment:3 by DrPepperAndPizza, 12 years ago

I ran the command to force the name change on the wifi nic:

VBoxManage modifyvm 717a337d-910e-42d5-a8b0-e05fc9d848e1 --nic1 bridged --bridgeadapter1 'en1: Wi-Fi'

And that took. In the VirtualBox Manager windows with the list of VMs on the left and the Details of the settings on the right, the name of the Network is updated:

OLD:

Adapter 1:

Intel PRO/1000 MT Desktop (Bridged adapter, en1: Wi-Fi (AirPort))

NEW:

Adapter 1:

Intel PRO/1000 MT Desktop (Bridged adapter, en1: Wi-Fi)

In the VirtualBox Manager window, I click on the VM to highlight/select it on the left -> "Settings" -> "Network".

For "Attached to" pull down menu, select "Bridged Adaptor".

Then for "Name", the old wifi name "en: Wi-Fi (AirPort)" in the pull down menu it still shows up! There is no choice for "en: Wi-Fi".

So when I select "en: Wi-Fi (AirPort)", the Details show "en: Wi-Fi (AirPort)", not "en: Wi-Fi".

Does this provide any clues? Where is it still getting "en: Wi-Fi (AirPort)"?

Version 0, edited 12 years ago by DrPepperAndPizza (next)

comment:4 by DrPepperAndPizza, 12 years ago

So I deleted my VMs. Installed from ISO a new Debian 6 installation. Set to NAT so that it could retrieve packages during the install.

After the installation, I shutdown the guest, switch the NAT to Bridged Networking and started the guest. In the Guest, I set /etc/network/interfaces to a static IP in the same range as my Host. Then rebooted the guest.

Now I'm getting a strange behavior. The host loses connection to the router 192.168.1.1 = router (iptables with Debian 6.0.5) 192.168.1.10 = host OS (Mac OS X 10.7.4) 192.168.1.100 = guest OS (Debian 6.0.5 64-bit)

Pinging scenario 1:

  • pinging from host to router works.
  • pinging from host to guest works.
  • pinging from guest to router does NOT work.

When I stop the wifi and restart, the same occurs, but when I ping from guest to router, the pinging from host to router dies.

I have to stop/start the wifi, we go back to scenario 1.

It's either the host can ping the router or the guest can ping the router, but not both at the same time.

If I leave the pinging running in the Guest, eventually the guest can ping, but the ping from host to router dies. After about 10-20 seconds, it goes visa-versa (the ping from guest to router dies, and the ping from host to router starts working again.

The ping from host to guest never has any problems.

comment:5 by dportabella, 11 years ago

I have the same issue on my Mac book air, OSX 10.8.4.

Any solution to this issue?

comment:6 by drkn, 10 years ago

Any update on this - or at least a workaround? Having an ethernet cable plugged in just for vbox is a pain.

comment:7 by Oliver Drummond, 10 years ago

Having the same problem, can only connect in Bridge Mode on my Mac if I use a cable connection. Any news about this?

comment:8 by tmas, 10 years ago

Hi, having the same issue on my macbook air. Any updates about this issue?

comment:9 by lidaobing3, 10 years ago

Any update on this - or at least a workaround?

Thanks

comment:10 by Os, 10 years ago

Hi, I have a Macbook Air as host and having the same problem. Any update of using bridged adapters over WiFi ?

comment:11 by phillipbarron, 10 years ago

I have a MacBook Pro running Mavericks and have the same issue - I am running Virtual box on a Windows 7 machine too and have no problem bridging the Wireless network adaptor to the VM running Debian 6.0.6.

The problem then seems Mac specific - The Mac is my Main Dev machine and not being able to get an IP from the Wireless Adapter is a real headache. This support ticket is already 2 years old ! - I will submit another in the hope that someone will look again or, at the very least, respond. If this is not going to be fixed, please state that this is the case.

comment:12 by obduk, 10 years ago

So far I have found out this seems to be something to do with VirtualBox not working on mac os wirless when IPv6 is enabled, however following these instructions I have still not got it to work:

https://forums.virtualbox.org/viewtopic.php?f=5&t=12887 https://discussions.apple.com/thread/3757967?tstart=0

comment:13 by cerberos, 10 years ago

I have this problem with a new MBP with Mavericks running virtualbox 4.3.10, it's not related to IPV6 as I've turned it off via

networksetup -listallnetworkservices (to find the available interfaces)
networksetup -setv6off Wi-Fi

MBPs don't have ethernet sockets any more so this is a major problem.

comment:14 by cerberos, 10 years ago

I setup some wireshark captures while running sudo dhclient eth0 -v with bridged ethernet and bridged wireless settings. There seems to be some duplicate packets that are issued with the mac address of the client then again with the mac address of the host, I don't know if that's correct or not. Here are the capture files.

https://dl.dropboxusercontent.com/u/45079992/bridged_ethernet1.pcapng https://dl.dropboxusercontent.com/u/45079992/bridged_wireless1.pcapng

For more background, see this thread. https://forums.virtualbox.org/viewtopic.php?f=8&t=60883&p=283490#p283490

comment:15 by Ingmar, 10 years ago

This is just to say "I have the same problem". I have e MBP 15" Retina with Mavericks. I cannot connect from the host to the VM (where I run Fedora 20). I don't know much about networking, but I have tried m best to follow the documentation, and follow various old advise on the internet. Nothing works. NAT always works fine, so I can connect from Fedora to the internet. I have tried pinging, with mixed results, at times I have been able to ping from Mavericks to Fedora, but have still not been able to connect via SSL or http. Very irritating, lots of hours spent to no avail. Banging on the MBP doesn't help at all. Maybe more force will do the trick?

comment:16 by VahidKowsari, 10 years ago

I had the same problem and it seems to work in one wireless environment and not in another. For me it worked at home, while the same exact configuration didnt work at work.

The way I did get it to work is turn on my MBP Internet sharing on and share my Wifi, with the VirtualBox VM guests. I shared it using the Thunderbolt Bridge interface. Then in each of the guest OSes, I set Virtual Box to Bridge and use the bridge0 interface.

Hope that helps somebody else.

comment:17 by Oleg Frayman, 10 years ago

+1 On working @ my house and not working @ work .... In my office selecting NAT works (Get Internet Connection) however Exchange server does not work as Reverse DNS is screwed up ...

Would be great if VB would fix this issue

Last edited 10 years ago by Oleg Frayman (previous) (diff)

comment:18 by Valery Ushakov, 10 years ago

This should be partially fixed in 4.3.16.

Many wifi routers now try to use unicast link-level destination for broadcast/multicast IP destination. The reasons are explained in http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01 - that is in context of IPv6, but the same logic applies to IPv4 (IPv6 is hit harder since it relies more on multicast). Behavior varies between wifi routers, so you may get bridged setup working with some and not working with others.

If the wifi router that is not working for you just uses unicast delivery for multicast, then 4.3.16 should help (a typical packet capture can be seen in #12207). In this case the host was receiving DHCP replies intended for the guest (broadcast IP, but unicast to host MAC), but was not rewriting MAC address correctly, so the guest was not receiving the packet. If you plug another computer into the wired port of the router to capture DHCP exchange as seen on the wired side, you would see the same DHCP replies sent to ethernet broadcast on the wired connection. So this is just an optimization for wifi that some routers do.

Unfortunately - and this is orthogonal to multicast/unicast issue above - some routers will send DHCP replies to broadcast IP, but to the unicast client MAC address (i.e. guest MAC in this case) fetched from the DHCP request. These packets will never be even seen by the host. I'm afraid the packet captures in comment:14 is an example of that. In the ethernet capture you can see DHCP replies unicast to guest and in the wireless capture you don't see any replies at all. I have one router like this (though it at least uses ethernet broadcast for its DHCP NAKs, so you can see something in the wireless capture :).

in reply to:  18 comment:19 by Valery Ushakov, 10 years ago

Replying to vushakov:

This should be partially fixed in 4.3.16.

[...]

Unfortunately - and this is orthogonal to multicast/unicast issue above - some routers will send DHCP replies to broadcast IP, but to the unicast client MAC address (i.e. guest MAC in this case) fetched from the DHCP request. These packets will never be even seen by the host. I'm afraid the packet captures in comment:14 is an example of that. In the ethernet capture you can see DHCP replies unicast to guest and in the wireless capture you don't see any replies at all. I have one router like this (though it at least uses ethernet broadcast for its DHCP NAKs, so you can see something in the wireless capture :).

[Sorry, accidentally sent too early...]

This latter kind of routers has problems with DHCP, but usually you can work around it by not using DHCP and using static IP instead. E.g. I cannot connect to that router of mine with DHCP, but if I use static IP in the guest then I get normal connectivity. Yes, this is suboptimal :(, but better than no connectivity if you must use bridged for some reason.

comment:20 by stevenstromer, 9 years ago

Unless I am mistaken regarding the issue here, simply allowing ip forwarding on the OSX host will resolve the issue:

sudo sysctl -w net.inet.ip.forwarding=1

in reply to:  20 comment:21 by Valery Ushakov, 9 years ago

Replying to stevenstromer:

Unless I am mistaken regarding the issue here, simply allowing ip forwarding on the OSX host will resolve the issue

No, bridged traffic doesn't go through host's routing.

comment:22 by vladkd, 6 years ago

It's been 7 years. Any updates yet?

comment:23 by Valery Ushakov, 6 years ago

Resolution: fixed
Status: newclosed

See comment:18 and comment:19 above. It's a bug in the DHCP server in your AP/router.

comment:24 by Socratis, 6 years ago

But, vushakov, is it actually a bug? If I'm not mistaken, the specification does not allow for Bridged-over-WiFi. If it happens, it's because the AP/router's manufacturers don't actually follow the spec, but they relaxed it so that Bridged-over-WiFi is supported.

In other words, it's not supposed to work, and if it does, it's because someone didn't follow the spec to the "T". Do I have it wrong?

comment:25 by Valery Ushakov, 6 years ago

Which specification do you mean?

I don't think that IETF draft was ever promoted to something more binding, and it only talks about IPv6. Obviously AP manufacturers use similar optimizations for IPv4 too (for the same reasons), but there's no official spec to follow.

Now, my memory is hazy, but the summary of what's going on here is roughly like this:

  • Guest sends DHCP request with its MAC in chaddr
  • We tweak the packet to make sure the DHCP broadcast flag is set
  • The packet is sent with hosts MAC as source (as all packets are with bridged-to-wifi)
  • The server should reply with a broadcast, but tries to optimize and use unicast instead
  • Correct optimization is to send unicast to the host's MAC (source MAC of the DHCP request as seen by the server).
  • Bad optimization is to send unicast to the MAC from chaddr (VM's MAC).

The latter obviously doesn't work as the packet never reaches the host and hence the guest.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use