DHCP Offer without MAC broadcast but explicit MAC address

[wegmann]

Running host on MacBook Pro Retina with a single WLAN interface and guest Windows XP or Linux (doesn't matter). If the guest makes a DHCP request (DHCP Discover) I see on the host the DHCP Offer from the DHCP server having on the ethernet layer the MAC from the host instead of the broadcast (ff:ff:ff:ff:ff:ff). It seems that network filter (or whatever) from VirtualBox doesn't recognize this DHCP Offer and doesn't translate the MAC address from the host to the MAC address from the guest like it does after it learned the MAC address and the corresponding IP address. I know the best would be when the DHCP server would send the DHCP Offer with the broadcast address. I think as long Virtual Box hasn't learned the MAC, it should not only listen on DHCP Offers having a broadcast MAC address but also on the DHCP Offers having the MAC address from the host and translate them to the MAC address of the guest if the DHCP field (Client MAC address) points to the MAC address of the guest.

[ChipMcK]

Network adapter set to NAT or Bridged or Host-Only?

Best

[wegmann]

I am sorry that I forgot the mention that. The problem appears with the Bridged Adapter. Independent which Promiscuous Mode is set. If I enable the promiscuous in the guest OS (in Linux this is easy), the DHCP works, because the guest OS checks the network traffic also if the ethernet MAC address points to the host. But this is in my opinion not the right solution. I think it can be fixed in the network filter that Virtual Box loads in the host OS.

[noteirak]

Could you provide a VM log file, guest settings as described here.

Also, provide the following information from the host & guest (not sure if the commands will work on OSX) :

Code: Select all

sudo ifconfig -a
sudo route -n

[wegmann]

Would it be also okay if I just post the Wireshark protocols? One protocol where DHCP works and one where DHCP doesn't work. I can show you the difference on the ethernet protocol level and I am nearly 100% sure that I located the "problem".

[Martin]

The problem most probably is that promiscous mode doesn't exist in the WLAN specification. (and your WLAN card or router follows the specification too much )

[noteirak]

If you are fine to troubleshoot this and have tehcnical evidences of the issue, then the best place would the bugtracker really. You can then add the Wireshark info directly.

[wegmann]

Thank you for your fast answers. I opened a ticket #12207 in the public bugtracker.

[wegmann]

Nobody cares about this ticket

[wegmann]

Can somebody have a look at the ticket #12207?

[Martin]

It seems that this is too the same problem that bridged networking is outside the WLAN specification.
Promiscous mode doesn't exist in the official WLAN specifications.
Some combinations of Routers/Access Points, WLAN cards and drivers work, some don't.

[wegmann]

Have you seen my Wireshark explanation in the ticket? The DHCP packets reach the Virtual Box code, only a network filtering on the guest network interface is required. It relies on the network interface of the guest system which Virtual Box provides. It is not the host network interface that blocks any packages. I am sure that a developer from Virtual Box where to put the code. The fact that Parallels can handle it too on the same machine means that it is solvable in the implementation. And let's say, I am a big fan of Virtual Box!

[wegmann]

I run VirtualBox on a MacBook Pro Retina (with a single WLAN interface) and as guest OS Windows XP or Linux (doesn't matter) using a single bridged interface in the guest OS which points to the WLAN interface on the host.

I attached an image with 4 Wireshark screenshots which describes the problem:

On both sides you see the beginning of a DHCP sequence. The left side will succeed but the right side wont.

As you can see on both sides the DHCP Discover packet from the guest OS looks the same.

The difference is in the DHCP Offer packet from the DHCP server. On the left side the destination on the Ethernet layer is a broadcast MAC address (A) and on the right side it is the MAC address from the host (B), which is the MAC address of the WLAN interface of the MacBook Pro.

I didn't attached an image of the Wireshark packets in the guest OS, but I have seen that the DHCP packets are passed unchanged to the guest OS.

I think this makes sense because the network filter from VirtualBox didn't have the chance to learn any IP address and is therefore not able to translate the MAC address from the host to the one from the guest OS.

It makes also sense that the guest OS ignores the DHCP Offer because the destination MAC address is neither a broadcast MAC address nor the MAC address of the guest OS.

Linux (but not Windows XP) is smart enough, that if the promiscuous mode on the network interface in the guest OS is enabled, it accepts the DHCP Offer. Linux can do that because the real MAC address of the guest OS is stored in the DHCP Offer in the BOOTP Protocol in the field "Client MAC address" see label (C) and (D) in the image. On both sides (left and right) the MAC address is the one from the guest OS.

And I think this is the solution for VirtualBox: If the network filter detects a DHCP Offer with a destination MAC address that matches the one from the host AND if the "Client MAC address" matches the MAC address from the guest OS it replaces the destination MAC with the one from the guest OS.

Or simpler, destination MAC addresses of DHCP Offers are set to the broadcast MAC address ff:ff:ff:ff:ff:ff.

[wegmann]

Any news?

[Martin]

Bridging is still outside the WLAN specification.