Google cast devices disappear

[caeci11ius]

On 18.06RC2, but consistent problem over various versions...

My network consists of three OpenWRT devices - 2xWNDR3700s used as dumb APs (as much disabled as possible) and an Asus RT-N56U used as a router (wifi disabled). 802.11R is enabled on the two APs and seamless roaming is working well. IGMP snooping is disabled on all the bridges.

WNDR3700#1 ))) ~~~ ((( Google cast devices
|
|----- RT-N56U ----- Modem ----- Internet
|
WNDR3700#2 ))) ~~~ ((( Google cast devices

The problem in having is that my five Google cast devices are not always discoverable. They work well temporarily if WiFi is restarted on the APs, but invariably over time some will cease being discoverable. Nothing seems to help.

Other things that rely on multicast DNS are working fine (Apple Time Machine springs to mind).

I might add that sometimes it will only detect the cast devices that are attached to the local router, but other times it will detect all of them. As snooping is turned off in the interface settings I can't see why this would be the case...

Any thoughts? I'm at my wit's end...

[caeci11ius]

Ok so a bit more info:

Updated to 18.06.0, reset all devices to default configs. Reconfigured from scratch in case I'd done something strange to them over the last few years. No change, problem still occurs.

Once they stop showing up properly, the cast devices are accessible when connected to the wifi of the OTHER AP, but once they disappear are not available on the local router (e.g. when on wndr3700a, I can access discover and access settings for the cast devices on wndr3700b, but not those on wndr3700a).

I have now connected one of the cast devices via ethernet. This device does not disappear and remains available over time regardless of which AP my phone is connected to. So it would seem the issue is specific to wifi...

[tmomas]

Might be related:

Chromecast Audio Discovery

Hello, Just wondered if anyone else has had trouble discovering Chromecast Audio devices whilst using LEDE? I'm using the latest version (LEDE Reboot 17.01.4 r3560-79f57e422d) on a BT Homehub 5a and my device is cam be seem when I restart my router but then after about 1 hour I can no longer see it. Any help would be really appreciated.

[caeci11ius]

The OP there suggests installing luci-app-upnp, which I already have installed and setup in my installed images. Doesn't help.

There's also some speculation about the Chromecast broadcasting bug being related, but that was fixed back in January.

I did wonder if this might be related as I have a lot of wifi devices (perhaps 50):

https://bugs.openwrt.org/index.php?do=details&task_id=253

[miGi]

I had this problem. The reason was 802.11w Management Frame Protection. Chromecast is again working fine, when i disable Frame Protection.

That same reason I could not print form my wifi printer. My pc could not even ping the printer when that setting was on.

[mtis88]

I’m having this issue. Has anyone managed to work out what the problem is?

[GreenSystemAdmin]

I'm having similar, possibly related issues, in WISP mode:

Can only find Chromecast in Android apps for a short time after router restart

I have a NEXX WT3020 which I've been using with Padavan for some time, as the WiFi drivers for MT7620 were quite unstable on LEDE/OpenWRT. I saw a lot of improvements to the MT76xx drivers listed in the changelog for 18.06.4 so I thought I'd try it out, and it does seem to be a lot more stable. I use the WT3020 as a travel router, either hardwired from an ethernet port in hotel rooms to the WAN port of the WT3020, using Travelmate to WISP off the hotel WiFi or occasionally using my smartphone'…

When the Chromecast "disappears", I can still ping it from the router, and it still appears under "Network>Wireless>Associated Stations" and the Chromecast itself doesn't complain about lost connectivity. But I can't ping it from any other device on the LAN, nor select it as a casting target, until I either go to "Interfaces" and restart the LAN interface, or totally reboot the router.

I feel like it could be Multicast/IGMP related, but that area of networking is frustratingly cryptic to unpick for me...

[mtis88]

This was quite a simple and obvious fix for me in the end: enable IGMP snooping for the LAN interface.

[GreenSystemAdmin]

I tried enabling IGMP snooping on 18.06.4 and this didn't seem to work, so I decided to try the 19.07 SNAPSHOT that has Luci included instead:

https://downloads.openwrt.org/releases/19.07-SNAPSHOT/targets/

Glad to say that adding option igmp_snooping '1' to /etc/config/network under the LAN interface fixed this for me:

config interface 'lan'
    option type 'bridge'
    option igmp_snooping '1'

I also disabled legacy 802.11b rates (which can be done in the Luci GUI under "Network>Wireless>Edit>Advanced Settings" or by adding option legacy_rates '0' to /etc/config/wireless for the wifi-device):

config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/10180000.wmac'
option country '00'
option legacy_rates '0'
option htmode 'HT20'
option channel '11'

Relevant Wiki links:

https://openwrt.org/docs/guide-user/network/wan/udp_multicast
https://openwrt.org/docs/guide-user/network/wifi/dumbap

Thanks @mtis88!

[caeci11ius]

I'm a little surprised enabling IGMP snooping is helping people...my understanding of that is that it's supposed to enable forwarding of multicast traffic only to interfaces where devices are subscribed to it. Many wifi APs have broken implementations of the feature, which can actually cause this particular issue. That said, if anything, openwrt is likely to have a better than average implementation so certainly worth giving it a go if it's helping folks. That said, cast ought to work even with IGMP snooping turned off (as all packets should go to all interfaces in this case).

If anyone is interested, I actually never did manage to get this working on my WNDR3700s. After a few months of tearing my hair out and trying everything i could find (and given my APs were getting on a bit anyway), I ended up just getting jack of the problem and solving it with money - bought a pair of Ubiquiti NanoHD APs (which are awesome - highly recommended). Cast is working, and I have snooping disabled on those...

I really am heartened to hear that people are having success with the 2019 builds though...this is obviously a really important feature (certainly was for me with 8 or 10 Google cast devices in the house). I do still use OpenWRT as a router running on a raspberry pi - the SQM QoS is hard to beat...

[GreenSystemAdmin]

Actually, this was a false positive for me. Enabling IGMP snooping seems to delay, rather than fix, the issue. Previously the Chromecast was disappearing after about an hour, but now it seems to last about 12 hours before it disappears.

My theory is that IGMP snooping helps because the interfaces are no longer flooded with multicast requests, and instead they are targeted. This means it takes longer before the interface is overloaded and drops? But I'm really stabbing in the dark there as I have no full understanding of the ins and outs of multicasting.

I've got a Gl.iNet ARM300M here that I'm going to try instead to see if it handles the Chromecast more consistently.

I too use Ubiquiti APs on their firmware with a controller at home and it blows anything else I've used out of the water. I combine this with an Archer C7 V2.0 on OpenWRT, also for the excellent SQM. Not so practical to pack one on my travels however...

[GreenSystemAdmin]

Yup, 2+ days uptime on the Gl.iNet AR300M with the same setup and the Chromecast remains visible. Have to put this down to the much less mature Mediatek platform of the WT3020 when compared to the rock solid Atheros of the AR300M.

[mtis88]

OK so it lasted 6 days with IGMP snooping enabled and it's now stopped working again. I'm using the Netgear R7800.

I just disabled IGMP snooping and without restarting the router or any of the devices it started working again. I'm considering a nasty fix along the lines of running a cron job every night to toggle the state...