[vbox-dev] Setting the hardware MAC address on a virtual Ethernet interface is not working correctly

[Aleksey Ilyushin]

David,

Yes, right, missed it. When you are talking about enabling promiscuous mode inside VirtualBox (console), you are referring to ‘promiscuous mode’ parameter in adapter settings, right? The one that can be ‘Deny’, ‘Allow VMs’ or ‘Allow All’? This one has no effect on guests’s interface settings. It is intended to prevent guests from sniffing host’s or other VM’s traffic. So when you ‘allow’ promiscuous mode for an adapter, it merely informs our internal switch that it should allow delivering all packets (coming from other VMs or, in case of ‘allow all’ from the host as well) to this adapter. Now if you have not put guest’s interface into promiscuous mode, the adapter won’t get all packets because virtio device has never received VNET_CTRL_CMD_RX_MODE_PROMISC from the guest’s driver, hence, it has not notified our switch that the adapter is in promiscuous mode via pfnSetPromiscuousMode callback. This is by design — if guest does not want all packets, it won’t receive all packets.

The code that does it is here: https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/SrvIntNetR0.cpp#L1672

The function that is called (not directly) via pfnSetPromiscuousMode callback is here: https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Network/SrvIntNetR0.cpp#L4282

Regards,
Aleksey

On 25 Aug 2016, at 17:06, David Garrod <dgarrod at extremenetworks.com> wrote:

> Aleksey,
> 
> Many thanks for your answer. But I still don't fully understand what is happening. Specifically I stated:
> 
>> System A sends a Broadcast ARP to resolve the MAC address for B. This packet is received by system B and of course a UNICAST reply is sent back with the resolution for MAC B.
> 
>> System B then sends a unicast ARP packet (source MACB dest MACA) asking for the resolution of systemA's MAC.
> 
>> The pcap trace file I've put on System B's NIC (foobar2.pcap) shows all of these packets. But the pcap trace file on system A (foobar.pcap) only shows the original ARP broadcast packet from system A to system B. It does NOT show either of the Unicast replies. So of course they don't make it into the System A Libux system and hence the ping doesn't work.
> 
>> This is the behavior I'd expect had I not set promiscuous mode on the virtual NICs inside VirtualBox. But I have set promiscuous mode and I cannot understand why it is not working.
> 
>> Various web searches led me to one post that said that PROMISC mode in VirtualBox has no effect unless the guest has set the interface into promiscuous mode. Indeed I found this to be true. Once I set promiscuous mode on the guest the Unicast packets got through.
> 
> So given I've set the interfaces into PROMISCUOUS mode from the virtualbox console why are the Unicast packets not being delivered to "system A's NIC"? From what you say it sounds like the MAC I've programmed on system A's NIC isn't being properly communicated to the internal switch as a MAC when packets with that MAC as the source MAC appear (i.e. that MAC is not learned) But even if this is not the case how come PROMISCUOUS mode in virtualbox doesn't deliver all packets to system A's NIC regardless of destination MAC. As I stated if the guest sets promiscuous mode on the NIC then the packets are delivered. So does this mean that this promiscuous mode setting is being communicated? Why is the setting of promiscuous mode in virtualbox contingent on promiscuous mode being set inside the guest?
> 
> Could you give me a pointer to the code you are referring to inside Virtualbox at https://www.virtualbox.org/browser/vbox/trunk As I said I did look here but I got lost.
> 
> Thanks.
> 
> ________________________________
> 
> DISCLAIMER:
> This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.
>