[Bug]: Linux shared-MAC Wi-Fi bridge skips multicast receive setup, breaking IPv6 neighbor discovery

Start with src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c, especially vboxNetFltPortOsSetActive, and trace how the shared-MAC flag reaches the Linux filter. The report identifies the missing multicast receive setup and describes a locally tested all-multicast prototype, but leaves upstream policy and lifecycle handling for review. Check activation, deactivation, and interface state handling; done means shared-MAC guests receive required multicast traffic while normal promiscuous bridging behavior is preserved.

Version

7.2.22 r175245

Host OS Type

Linux

Host OS name + version

Ubuntu 24.04.4 LTS, kernel 7.0.0-42-generic; NetworkManager 1.46.0.
Intel Wireless-AC 9560 using iwlwifi.

Host Architecture

x86 (x86_64)

Guest OS Type

Linux

Guest Architecture

x86 (x86_64)

Guest OS name + version

Home Assistant OS 18.4; Core 2026.11.0. Emulated Intel 82540EM adapter, bridged to the host's Wi-Fi interface.

Component

Network

What happened?

The guest intermittently loses IPv6 reachability to Matter-over-Thread devices while the Ubuntu host can still reach those same devices. Restarting only a Nest Thread border router reproduced a persistent guest-only outage. Guest routes remained valid.

The investigation points to missing multicast receive setup in VirtualBox's Linux shared-MAC Wi-Fi bridge path. The guest has joined its IPv6 solicited-node multicast group, but the corresponding multicast MAC is absent from the physical host interface's receive list. The host interface has both promiscuity and allmulti counts at zero.

Adding just the guest's solicited-node multicast MAC to the host interface with ip maddress add allows fresh neighbor discovery to reach the guest and restores connectivity. Controlled removal/restoration of that entry reverses the receive failure. This report concerns that omission; it does not claim to explain every Wi-Fi multicast loss.

Expected behavior: a bridged guest should receive the IPv6 neighbor-discovery multicast traffic needed for its assigned addresses without a manually maintained host entry for each guest address.

How can we reproduce this?

The following sequence was exercised on the setup above:

1. Bridge the guest to a Linux host Wi-Fi interface using VirtualBox's shared-MAC mode. Confirm SharedMacOnWire=1 in the VM configuration/log.
2. Let the guest acquire an IPv6 address and join its solicited-node multicast group. Choose a group that the host is not already listening for on its own behalf.
3. Inspect the host with ip -d link show and ip maddress show: in the failing state, promiscuity=0, allmulti=0, and the guest's multicast MAC is absent.
4. From another LAN machine, send multicast echo probes to the guest's solicited-node group. Capture on the host with tcpdump -p so the capture does not enable promiscuous mode. In our final controlled comparison, the probes failed 0/3 and their requests were absent from the host capture.
5. Add the corresponding multicast MAC on the host interface. After allowing the receive filter to settle, identical probes succeeded 3/3 and the guest replied. Remove/restore the entry to reproduce/reverse the failure.
6. For the observed application-level trigger, power-cycle only the Nest border router. With the unmodified driver and no manual entry, guest-to-device probes failed 0/5 while host-to-device controls succeeded 3/3. Adding the entry allowed Nest's fresh multicast neighbor solicitation to reach the guest, the guest answered, and guest connectivity recovered.

The independent multicast probe avoids requiring Matter application state to demonstrate the receive problem. Whether other host/adapter/AP combinations reproduce it remains unverified.

Source-level diagnosis

The observed configuration selects this path:

SharedMacOnWire -> INTNET_OPEN_FLAGS_SHARED_MAC_ON_WIRE -> INTNETTRUNKFACTORY_FLAG_NO_PROMISC -> fDisablePromiscuous.

In the Linux filter, vboxNetFltPortOsSetActive returns immediately when fDisablePromiscuous is true. That file has no alternative dev_set_allmulti or dev_mc_add setup for guest multicast reception. Its normal path requests promiscuous reception instead.

Public source references, pinned to GitHub mirror commit b6bea72111fcff48f31c57c9f66365b1d3301bb9:

• Linux activation path and early return
• Shared-MAC flag selection
• Trunk creation passing NO_PROMISC

The installed Linux filter source and the mirror file inspected have identical functional code; their Id/copyright headers differ. I have not verified whether canonical SVN or an unreleased test build already addresses this.

Candidate approaches for maintainer discussion

A. Reference-counted all-multicast reception for shared-MAC bridges (locally tested prototype).

Request dev_set_allmulti(..., +1) while a NO_PROMISC/shared-MAC bridge is active and release that reference on deactivation. Track multicast ownership separately from promiscuous ownership; use consistent handling across activation/deactivation and interface up/down. Preserve ownership state if the kernel API fails. Normal bridges retain their promiscuous-reception behavior.

This avoids hard-coding guest addresses and avoids enabling promiscuous unicast reception. The tradeoff is broader multicast reception, with potential extra processing/power cost. Whether this is the desired upstream policy needs maintainer review.

B. Track and synchronize guest multicast memberships to the physical interface (not implemented or tested).

Maintain only the required multicast MACs, with reference counting across guests and correct handling of joins/leaves, address changes, reconnects, and teardown. This would narrow reception, but requires more state and a reliable way to learn guest memberships, including their lifecycle. I am not assuming that simply parsing MLD packets is sufficient in every case.

The current manual per-address entry is useful as a diagnostic/workaround, but is not proposed as the general upstream fix.

Validation of candidate A

A local prototype was compiled against the running host kernel and temporarily loaded for testing. The packaged module on disk was left unchanged.

• VM startup automatically acquired allmulti=1 while promiscuity remained 0.
• VM pause released the reference to 0; resume reacquired it to 1.
• With the original per-address entry removed, all five Matter nodes were available and guest-to-bulb probes passed 5/5.
• Repeating the Nest power cycle under the prototype, still without the per-address entry, showed fresh multicast neighbor solicitations reaching the guest for both its ULA and link-local addresses, followed by guest advertisements. All five nodes remained available afterward; bulb probes and direct guest-to-Nest probes each passed 5/5.
• An isolated harness using the actual helper/callback source and simulated kernel calls checked wired/shared-MAC selection, existing external references, duplicate events, reconnect/inactive state, and enable/disable failures. This is not a substitute for broader kernel integration testing.

Limitations

Independent multicast echo tests still showed loss in some runs, including 6/10 responses with all-multicast enabled. Received requests were answered; missing requests were absent from the host capture. This residual loss has not been isolated. Guest startup also took roughly 80 seconds to receive router advertisements during one run.

Multiple VMs, physical Wi-Fi reconnect under the prototype, whole-host suspend, long-term stability, other adapters/kernels, and real wired-interface regression coverage remain untested. The prototype is evidence for the proposed diagnosis and approach, not a merge-ready or universally validated fix.

Diagnostic material

Anonymized diagnostic excerpts are now available: network configuration, multicast probe results, fresh neighbor-discovery exchanges, and driver lifecycle counters. Network addresses and interface identifiers are replaced with consistent role labels. These are selected excerpts, not a full VBox.log; raw logs, binary packet captures, screenshots, and identifier mappings are not uploaded.