arp fails when connecting to a wireless connection on host via bridged network

[lerdmann]

Host: Windows 10 Pro Guest: eCS 2.2 beta (drivers: all the latest and greatest)

From the guest, I am trying to connect to a wireless connection on the host. For sake of simplicity and performance I have set up "bridged network".

Sometimes but not always I have problems to access the net from the guest. When that happens, I see this (example) in the ARP table of the guest:

"arp -a":

ARP table contents:

interface   hardware address   IP address       minutes since last use
lan 0       (incomplete)       www.xxx.yyy.zzz  0

Apparently, the ARP request does not pass through. If I reboot the guest a couple of times AND if I actually use the wireless connection on the host, then eventually, I will be able to access the wireless connection from the guest. I have not observed this problem with a wired connection (on the host). This seems to always work ok.

[lerdmann]

Here we go again:

 "arp -a":

ARP table contents:

interface   hardware address    IP address          minutes since last use
lan0        (incomplete)        www.xxx.yyy.zzz     0 

[Socratis]

1. "(incomplete)" is not a valid MAC address and "www.xxx.yyy.zzz" is not a valid IP, that's why it fails!
   (joking of course ;) )

2. It's a known issue. See comments 18 and 19, from ticket #10019: Unable to bridge Mac OS X AirPort connection. Actually read all the comments made by 'vushakov'.

3. Bridged over wireless don't always play nice. Bridged networking is outside the WLAN specification. Bridging to wireless is not really bridging. The guest shares the MAC of the host and the host does a sort of MAC-NAT translation based on IP addresses. Promiscuous mode doesn't exist in the official WLAN specifications. It may or may not work.

4. Some combinations of Routers/Access Points, WLAN cards and drivers work, some don't. See: ​Bridging & Wifi - Supported hardware and add your experience. For example, it works fine in my home, but not in my office. Same laptop, same VM, different router.

[lerdmann]

Hm, ...

1) I am not using DHCP but static IP addresses, therefore I can rule out the specific problem with DHCP 2) strange enough, wireless via bridged networking works MOST of the time but not always. In particular, it will START to work ok (if it did not already) as soon as I have a new MAC address generated for the guest lan connection and then restart the VM ! I have no clue why this is so.

Will it help if I move away from bridged networking and use NAT instead ? Is there a performance hit (for the guest) with that ? What are the restrictions with NAT ?
Problem is that from the VM I need to connect to a remote application on a specific target IP address and specific target port number. Since NAT mucks around with IP addresses and port numbers I have no clue if that will work with NAT ...

[Valery Ushakov]

Replying to lerdmann:

2) strange enough, wireless via bridged networking works MOST of the time but not always. In particular, it will START to work ok (if it did not already) as soon as I have a new MAC address generated for the guest lan connection and then restart the VM !

This is the first time you mention you are changing guest's MAC. Do you have more details on that?

Will it help if I move away from bridged networking and use NAT instead ? Is there a performance hit (for the guest) with that ? What are the restrictions with NAT ?
Problem is that from the VM I need to connect to a remote application on a specific target IP address and specific target port number. Since NAT mucks around with IP addresses and port numbers I have no clue if that will work with NAT ...

NAT cannot muck around with destinations. Despite its best efforts the remote server will not suddenly start listening on a different port :)

[lerdmann]

True, initially I forgot mentioning that changing the guest's MAC helps with the problem.
I would need to retest and observe over a longer time frame if it is ALWAYS true, but my experience is that if bridged networking over a WiFi connection fails that I can then shut down the guest, change the guest's MAC address via the VBOX Gui and then restart the guest and using the WiFi connection from the guest will work.My vague assumption is that that will somehow allow the ARP request from the guest to succeed.I don't know if this effect is somehow related to what the host does, I am using Windows 10 as the host (but in that respect Windows 7 behaved in the same way).
Maybe somebody else with the same problem can try that same thing as see if it makes a difference for him ?

By the way: all network interfaces (wired and wireless) on the host get their IP address via DHCP. It is only the guest that uses a static IP address. Maybe that is relevant ...

[Valery Ushakov]

Does it help to shutdown/close/restart or save/restore the guest without changing its MAC?

[lerdmann]

No, that does not help, at least not in any systematic way.
It only seems to succeed (occasionally) if the wifi connection is in use by the host for some indeterminate amount of time (my initial comment stated conditions when NOT changing the MAC address).