The cast button is gone from the app. Or the smart speaker works from one phone and not from another. Or everything worked until you added a guest network or an IoT VLAN, and then it stopped.
What it is not: a broken TV or speaker. Casting starts with discovery, and discovery uses mDNS (Apple, Google) or SSDP (DLNA, many TVs). Those are multicast messages inside one network. If the device is found but the stream itself fails, that is a bandwidth or firewall question, not this one.
The quick checks, in order
- Are the phone and the TV in the same network?
/ip dhcp-server lease print. Two addresses from two ranges is the answer straight away. This is the cause in most cases. - Do they see each other at IP level? Ping the TV from the phone with a network tool, or from the router:
/ping 192.168.30.40. No answer while the address is right means something is in between: client isolation or the firewall. - Do the discovery packets arrive?
/tool torch interface=bridge port=5353for mDNS, orport=1900for SSDP. A good answer is a handful of small packets the moment you open the app. Nothing at all means they never even reach the router. - Is anything being dropped?
/ip firewall filter print statsand/ip firewall raw print stats. Look for a drop rule whose counter moves exactly when you try to cast. - Is IGMP snooping on?
/interface bridge printand look atigmp-snooping. Not a fault in itself, but a suspect: see below.
The usual causes, most common first
The phone and the casting device are in different VLANs
By far the most common. TVs, speakers and small cameras often end up in an IoT VLAN while phones stay on the ordinary network. Multicast is not routed, so the discovery messages never reach the other side. Adding a firewall rule does not fix this: the messages are not being blocked, they are simply not forwarded.
The practical fix is to put the TV and the phone in the same network. If you insist on keeping them apart, you need an mDNS relay on a machine that sits in both networks, and that lives outside the router.
Client isolation is on for the SSID
A guest SSID with isolation makes devices on that same SSID invisible to each other. If the phone and the speaker are both on the guest network, casting does not work there either. That is exactly what isolation is for.
A firewall rule that blocks multicast on the LAN
This is a trap from a lot of guides. The bogon list contains 224.0.0.0/4, and blocking that as a destination on every interface destroys mDNS (224.0.0.251), SSDP (239.255.255.250) and OSPF on your own network. No AirPlay, no Chromecast, no printer discovery, and no error message that explains any of it.
IGMP snooping without a querier
IGMP snooping sends multicast only to ports that asked for it. That is exactly what you want for a TV stream. But without a querier on the network the bridge cannot maintain the memberships, and snooping can filter away traffic that was needed. If casting fails and snooping is on while you do not have IPTV, turn it off and try again.
Two networks with the same name
A phone on the 5 GHz SSID and a TV on a separate 2.4 GHz SSID that sits on another VLAN looks like one network and is not.
What the configurator does about it
- The firewall the tool writes applies the bogon rule for 224.0.0.0/4 as a destination on the WAN side only. That is a deliberate departure from the example in the manual, precisely because the same rule on every interface kills AirPlay, Chromecast and printer discovery on the LAN. Bogons are an internet problem, so the rule belongs on the internet side.
- Client isolation is a per-SSID toggle in the Wi-Fi section, and per SSID in the CAPsMAN section. Turn it on for guests and casting inside that network goes with it.
- Isolated per VLAN in the VLANs section does the same at network level: that VLAN talks only to the internet.
- With Traffic between VLANs set to "matrix" in the Firewall section you decide per pair who may start connections. That helps the stream itself once a device has been added by hand, not the automatic discovery.
- IGMP snooping is a bridge toggle in the Bridge & ports section, off by default. It is there for IPTV; casting does not need it.
- On the network board you can place a TV, speaker or other device as a client node with a VLAN. The check then reports it when the switch it is cabled to does not carry that VLAN.
The honest limits
There is no control in the tool that lifts multicast across a VLAN boundary, because RouterOS has no such function in the main package. Anyone who wants TVs and phones separated and wants to cast has to pick one or add software. Beyond that, the device decides a lot by itself: some TVs only search at boot, some apps fall back to a cloud connection when local discovery fails, and a Chromecast once paired to another Wi-Fi network keeps looking for that one until you set it up again.
Read on: Recipe: IoT network, Firewall and VLANs.