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

[Aleksey Ilyushin]

Hi,

Please see my explanations below.

Regards,
Aleksey

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

> Thanks again.
> 
> Re:
> 
>> 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'?
> 
> Yes that's exactly what I'm referring to.
> 
> Re:
> 
>> 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.
> 
> Thanks for the explanation. That makes sense to me.
> 
> But here is what I don't understand. In summary here is the behavior I see (I hope my table formats correctly when posted...
> 
>                                                                                         NIC in DENY Mode    NIC in ALLOW_VMs Mode
>                                                                                         ---------------------------------------------------------
> 
> 1) Guests Do not set MAC Address                            Works                    Works
> 2) Guests Set MAC Address Not PROMISC mode    Fails                       Fails
> 3) Guests Set MAC Address and PROMISC mode    Fails                       Works
> 
> By "works" I mean that ping works between the connected interface. By "fails" I mean that the Unicast packets never make to the guest network stack. I if course understand line 1).
> 
> Is line 2) failing because the "switch" (i.e. the code you pointed me at) is not delivering the unicast packet to the simulated "virtio device”?
Yes, the “switch” is not delivering unicast packets with new destination MAC address because it is not aware of MAC address change.
> Or is it because the simulated device itself is deciding that the DEST MAC doesn't match its programmed MAC? I'm assuming the latter.
No, this is a wrong assumption. At least virtio device (to be honest I haven’t checked others) uses MAC address stored in PCI config space for unicast packet filtering. PCI config space is updated by Linux virtio driver.
> But if that is the case I don't understand the behavior of line 3. Obviously the "works" case is the switch delivering all packets to the device and then the device delivering the packets to the guest because it is in promiscuous mode regardless of the destination MAC.
Right.
> But I don't understand why the "NIC in DENY mode" fails in this case. Here I'd assume the switch would have delivered the packet to the device because it has LEARNT that MAC on that device. But if it had done that then the device would have delivered it to the guest because it is in "promisc" mode.
The switch does not deliver unicast packets, destination addresses of which do not match the old MAC address, because it is not allowed by “deny” mode.
> 
> I was reading the code and trying to understand exactly where it is broken so I can make a more intelligent bug report in the bug reporting system. Is the issue that the switch code (SrvIntNetR0.cpp) doesn't know the programmed MAC address for the NIC and hence drops the packets. Or is the issue that the virtual NIC device driver in virtualbox is ignoring the programmed MAC address and hence dropping the packets when delivered to it by the switch code?
The problem is that currently there is no mechanism in place for emulated devices to notify the switch of MAC address changes by the guest.
> 
> With this additional information I will make a bug report and with that info hopefully there will be a chance of it being fixed. Or maybe I could try a test build to fix it.
> 
> Thanks,
> 
> Dave
> 
> ________________________________
> 
> 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.
>