DHCP Offers without a MAC broadcast address but explicit MAC address are not handled correct for bridged WLAN interfaces. => Fixed in SVN

[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]

Wireshark screenshots.

[wegmann]

Why nobody cares about this bug?

[Frank Mehnert]

Bridged WLAN is more a hack and needs fundamental changes. And we have our priorities, sorry.

[Valery Ushakov]

I think this should be fixed in 4.3.16.

Many wifi routers now try to use unicast link-level destination for broadcast/multicast IP destination. Behavior varies between wifi routers and I don't have one that exhibits this specific behavior, but the code to handle it is now there.

[Frank Mehnert]

Fix is part of VBox 4.3.16.