RBE971 / 12.1.10.12 NA: 224.0.0.0/24 multicast dropped on Wi-Fi, mDNS discovery broken

I've spent the better part of a week chasing this and I believe it's a firmware problem rather than anything at my end. Laying out what I found in case it's useful, and because there's a very similar report on another model.

The setup

Orbi 970 — RBE971 router, two RBE970 satellites, V12.1.10.12_5.3.16 (NA region), router mode behind a Verizon Fios ONT. Single subnet, roughly 63 clients. One satellite on wired backhaul, one wireless.

What's happening

Wi-Fi clients receive no inbound multicast addressed to 224.0.0.251. Wired clients on the same network receive it continuously.

That takes out every Bonjour-based service — printers, scanners, AirPrint — for anything on wireless. It surfaced as a printer that stopped appearing in Add Printer on two different Macs, but it's a good deal broader than printing.

The capture that settled it

MacBook, two metres from the router, -34 dBm on 5GHz:

sudo tcpdump -i en0 -n 'port 5353 and dst 224.0.0.251 and not src 10.0.0.16'

Sixty seconds of that: zero packets captured, out of 31463 received by the filter, none dropped by the kernel. The identical filter on a wired Mac mini — same LAN, same minute — scrolls continuously.

The client looks correct to me. netstat -gn lists the mDNS group against en0 with link-layer address 01:00:5e:00:00:fb, so both the IP membership and the hardware multicast filter are in place. It transmits multicast fine too — the same capture shows it sending PTR queries for the printing service types with the QM flag set, meaning reply by multicast. The query leaves. The reply never comes back.

What I've already ruled out

Signal and placement — -34 dBm at two metres.

The client — two entirely independent Macs, one personal and one a managed corporate machine, behave identically.

AWDL — disabled with ifconfig awdl0 down, no change.

The printer — advertises all its service types correctly, verified by browsing from the wired Mac.

Disable IGMP Proxying (ADVANCED / Setup / WAN Setup) — tested in both states, no difference.

The mesh — 63 hours of ping logging to the router and both satellites gives roughly 0.01 percent loss, median 2–3 ms, and not one sample above 50 ms from the wired client. This is not a coverage or stability problem.

One thing that misled me for a while: an iPhone on the same SSID works perfectly. I took that as evidence multicast was fine on wireless. It isn't — Apple's mobile stack sends QU queries requesting unicast replies, so an iPhone never needs to receive multicast at all.

Why I think this is a defect

That address is in the Local Network Control Block. RFC 4541 section 2.1.2 states that traffic to 224.0.0.0/24 must be forwarded on all ports regardless of IGMP snooping state. It isn't supposed to be filterable.

And before anyone suggests IGMP settings on the ONT: that address is link-local, TTL 1, and never touches the WAN, so nothing upstream can affect it. I mention it only because that's what support suggested in the thread below, where it wasn't applicable either.

A near-identical report on another model

Thread ID 2478846 on this board — "Orbi 37x and Local Network Control Block (224.0.0/24) multicast", June 2026. RBE371 with two RBE370s, so 770 series rather than mine.

Same filtering problem, same address block, and that poster independently describes "a difference between RBS/RBR ethernet port traffic management and wireless management." In his case the mDNS group still gets through and other groups don't; mine looks like a worse version, with the mDNS group itself gone.

Two model families showing the same class of problem points to something shared in the firmware rather than a model-specific fault. That thread is still unresolved and escalation was requested.

Three questions

Is this a known defect, and is there a tracking item I can be attached to?

The 12.1.11.10 release notes say it fixed "an IGMP snooping issue that caused satellite connectivity failures, and multi-device connectivity problems." Is that this? I can find no NA-region build newer than 12.1.10.12 — if that's the fix, is an NA release planned that contains it?

Failing that, is there anything supported I can change on 12.1.10.12 to restore forwarding of this address block to wireless clients?

Happy to provide full captures or run anything else that would help.