<div dir="ltr">Hi,<br><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 4:53 PM, Klaus Espenlaub <span dir="ltr"><<a href="mailto:klaus.espenlaub@oracle.com" target="_blank">klaus.espenlaub@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Maarten,<span class=""><br>
<br>
<div>On 06.08.2015 15:18, Maarten Hoes
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi,<br>
<br>
<br>
Well I finally figured it out. On my ISP's wifi modem/router,
there is a setting called 'DHCP Binding'. This can be used to
make sure that a certain MAC always gets the same IP address
assigned through DHCP. (essentially creating a DHCP scope of 1
single IP and 1 single MAC).<br>
<br>
When I enable this for a bridged host, reaching the default
gateway becomes impossible. I verified the MAC both in the VM
settings as in the guest os, and made sure that they match the
'DHCP Binding' settings on the modem/router. As soon as I
remove the entry from the modem/router and restart the guest,
networking resumes as expected.<br>
<br>
</div>
I had this setting enabled for the 'old' VM's, but not for the
newly created ones; which explains the difference in behavior.<br>
<div><br>
Now what I dont understand is why such a setting should/does
break bridged to wifi networking - especially when at the same
time NAT does work as expected with that setting enabled.<br>
</div>
</div>
</blockquote></span>
Taking a deep breath... let's start with the most surprising piece
of information for most people. Bridged to wifi actually isn't
deserving the name "bridging" at all. Bridging happens at the
Ethernet level, and with wifi that's not possible as 99% of the wifi
cards out there simply don't support promisc mode (which VirtualBox
uses for sending/receiving packets with the guest's MAC address).<br>
<br>
What "bridged to wifi" implements is a funky routing scheme, packet
filtering/suppression and some packet content rewriting. It entirely
shares the host's MAC address (and uses the guest's IP address for
actually filtering the traffic it needs to receive, so the host's IP
stack must not see the packets targeted at the guest and vice
versa), and convinces the wifi router's DHCP server to give out a
lease for each VM (which I guess is where your solution exploded)
even though the MAC address "on the wire" is always the host's. The
final step is to translate the host's MAC address to the guest's and
when the packets are passed to/from the VM.<br>
<br>
Klaus<br></div></blockquote><div><br><br>Thank you for taking the time to elaborate/clarify. It's appreciated. I guess what had me fooled is the fact that the bridged guest's MAC/IP combo's show up in the DHCP lease list on the wifi modem/router.<br><br></div><div>Anyway, I guess I now have a bug to close.<br><br></div><div>Thanks again,<br><br></div><div><br>- Maarten.<br><br></div></div><br></div></div>