Multicast originating from different subnet does not reach Guest only on Ubuntu(Linux?) Host

[idmistir]

Hello,

I have run into an issue that I now believe is a bug.

Basically, I am receiving status updates from various devices on the network in my VM. They use multicast on 224.0.0.50. The devices are on a different subnet from the Host and the Guest (the host and the guest are on the same subnet), but everyone can communicate between each other just fine. This works on Host Windows 10 but not on Host Ubuntu 18.04. Using Virtualbox 6.1.28.

Also, tried:

• 6.1.26
• 6.1.29 revision 148164 test build
• 6.1.97 development revision 148162

All the above w/ extpack

The guest is using bridged networking. On Windows it's using Intel PRO/1000 MT Desktop (82540EM). On the Ubuntu host I've tried them all with no luck. On Windows promiscuous mode is set to Deny and greyed out, on the Ubuntu host I tried enabling it to Allow-All, no luck.

Both hosts receive the multicast packet (used wireshark on windows and tcpdump on linux to verify on both the hosts and the guests), but only on the Windows 10 host will it manage to be picked up by the Guest. I'm attaching a screenshot from a packet capture from inside the Guest with Windows 10 as a host. These two packets are the expected behavior. On Ubuntu Host, only the first one (the direct reply) makes it all the way to the Guest. The multicast packet is lost.

It is worth mentioning that it's the exact same VM copied from Windows to Linux to make this test as good as possible.

Multicast packets originating from the same subnet are well-received. I also tried mimicking network routes on the Ubuntu host as seen on the Windows host but to no avail. I tried nuking the routes on the windows host to see if it affected the Windows Guest receiving it but it did not.

[idmistir]

Expected Packets as seen from Guest (on Win10 Host)

[idmistir]

VM log file (from Win10 Host)

[idmistir]

VM log file (from Ubuntu Host)

[Valery Ushakov]

I can't seem to reproduce this problem.

However, note that you use an address from the "Local Network Control Block" 224.0.0/24 (​RFC5771) that is "used for protocol control traffic that is not forwarded off link" (emphasis mine).

Linux and consumer routers don't seem to care much, and I actually can receive such packets originated in a different network inside a bridged Linux guest in a scenario that I believe to reproduce what you describe.

But note that e.g. NetBSD kernel won't even generate IGMP join messages for 224/24 (b/c no outside network should care), but if some other, more carefree machine on the same network joins this group and sends a join message (redundantly, if not, strictly speaking, incorrectly) and the uplink router notices that and (again, incorrectly, strictly speaking) forwards multicast packets originated in another network to the network where that NetBSD guest and that other machines are, then the NetBSD guest will receive that packet just fine.

So I would say that VirtualBox is unlikely to be the culprit. To reiterate, 1) the scenario as described in the report seems to work for me, even though 2) it is technically speaking violates RFC5771.