<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Maarten,<br>
<br>
<div class="moz-cite-prefix">On 06.08.2015 15:18, Maarten Hoes
wrote:<br>
</div>
<blockquote
cite="mid:CAHvU03Ub=4zC32yVfuHrLDnkw=q7kEbMizRdEEsLGXOm7SdFzg@mail.gmail.com"
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>
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>
<blockquote
cite="mid:CAHvU03Ub=4zC32yVfuHrLDnkw=q7kEbMizRdEEsLGXOm7SdFzg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="moz-signature"><br>
- Maarten.<!-- This signature was generated by the MyDesktop Oracle Business Signature utility version 4.2 -->
</div>
</div>
</blockquote>
</body>
</html>