internal network / switch implementation

[caliloo]

Hi all,

I'm using virtualbox in a scenario where I use one linux guest to simulate an industrial appliance using an adhoc ethernet protocol, and one guest to simulate a linux machine receiving those packets and processing them. Both hosted on one linux host.

The appliance and the linux machine are connected together via an ethernet link. I've tried "internal networks" and "bridged nics" (with a cable between 2 dedicated nics at the back of the host). (I've always set both nics in allow promisc all in the guest settings, and have verified basic connectivity works by setting up an ip on both and doing some pings,etc...).
In both cases I hit a problem :
Any packet sent with a destination mac of 88:88:88:88:88:88 by the appliance (don't bash me, I didn't design this appliance, and I can't change this) gets silently dropped somewhere between the sending and the receiving nic. I see packets leaving the sending nic, and none reaching the receiving nic.

Note that if I try to connect a real appliance to the bridged interface of the linux guest that's supposed to receive them. it works....Also, if I use packets with a destination mac of ff:ff:ff:ff:ff:ff (the classic broadcast packet) it works in all virtualised scenarios.

Now.. when I read the manual about internal networks (chapter 6), it says "The VirtualBox support driver implements a complete Ethernet switch and supports both broadcast/multicast frames and promiscuous mode". Well.... does it ? my hardware switches (have experience with dell force10's in 3 different flavors and hp procurves in 2 flavors) do forward 88:88:88:88:88:88 but not the VB internal network switch, or is it that the 88:88:88:88:88:88 somehow don't leave the appliance VM ? (I havn't tested the virtual appliance with a real switch thru bridged networks, but have tested a real appliance into a bridged VM, and that works)
I think it could be an implementation detail in the virtual nic driver, sender side. But I fail to find any details on how to tweak this.... (I've tried all possible guest nic types on the sender side ).

Is there a way to configure virtualbox nic or switch to make this work ?

Brgds.

[Martin]

Did you set the virtual nic to promiscous mode to allow other/special MAC addresses?
See VBoxManage modifyvm / controlvm parameter

Code: Select all

--nicpromisc<1-N> deny|allow-vms|allow-all: This allows you, for each of the VM's virtual network cards, to specify how the promiscuous mode is handled. This setting is only relevant for bridged networking. deny (default setting) hides any traffic not intended for this VM. allow-vms hides all host traffic from this VM but allows the VM to see traffic from/to other VMs. allow-all removes this restriction completely.

https://www.virtualbox.org/manual/ch08.html#idm3991

[socratis]

Just out of curiosity: why would a packet destined for 88:88:88:88:88:88 show in a VM that doesn't have that MAC? Honest question.

[caliloo]

@martin : yes I have (I says so in the post, 2nd text block), but thanks for asking. I'm also running the VM under the same user name (intnets are by default not interconnected when running VM under different host's user names...).

@socratis: the honest answer is : "I don't know" that being said, why would 5 different make/model of bare metal switches (with bare metal appliance and virtual or bare metal linux machine receiving them) behave that way if this wasn't correct behaviour ?

[caliloo]

Hi,

found my problem... turns out the linux listener did not always set it's the virtual card in promiscuous mode under some special conditions. So much for all this... Thanks anyway. It was also an interesting dive in the VBox code....

things like this for instance in the internal network driver lol

398 * Validate the override structure.
399 *
400 * Note! We're racing vboxNetFltLinuxUnhookDev here. If this was supposed
401 * to be production quality code, we would have to be much more
402 * careful here and avoid the race.
403 */

And that's just an example...