Getting Chromecast to work across subnets

Question

I know Google says its not supported. Has anyone got a Chromecast to talk to a client on a different subnet? I have an OpenWRT router connected to my internet providers router (parent router). The OpenWRT network is a different subnet and handles DHCP etc. OpenWRT Network (192.168.1.0/24) and parent network (192.168.11.0/24)

The chromecast is on the parent network, I want clients on the OpenWRT network to use the Chromecast.

I have enabled igmp_snooping, running igmpproxy and avahi-daemon in reflector mode. I can see Chromecast in bonjour explorer (from a machine on the OpenWRT network), but the Chromecast app won't connect.

I have also tried increasing the TTL on the OpenWRT router

iptables -t mangle -A PREROUTING -i eth0 -d 239.255.255.250 -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -i wlan0 -d 239.255.255.250 -j TTL --ttl-inc 1

Using wireshark I can see, that the chromecast and computer are speaking through subnets... but it still wont connect.

I can also ping the chromecast from the child network.

Anyone done this? Any pointers?

Answer 1

As far as I can tell the issue the only issue preventing Chromecasts from being used from other subnets is one of discovery which is dealt with by multicast UPNP packets which unfortunately have a TTL of 1. Instead of getting my router doing all of the usual multicast shenanigans and adjusting the TTL as you suggest, I wrote a python script to advertise my Chromecast on the other subnet. It is available on github.

Answer 2

I can see 2 potential problems.

1) Chromecast may be using a non-routing protocol. Think NetBIOS or IPX. Just because it and the device it attaches too are using IP for management, doesn't mean that the video packets can traverse that network device

2) You could be running into this routing problem as well. I have seen several problems with cheap network attached devices having trouble routing between 192.168 private networks. That network space wasn't designed for larger enterprise routing. We ran into a problem at one site when when tried to merge two adjacent ranges by adjusting the network masking. There shouldn't be an issue, but the router wouldn't do it reliably.

If you try instead, 10.x.64.0/23, you may have better luck. I suggest that range because it falls on an even bit pattern. It was a real hassle to switch all of the devices over and relink them, but it was implemented as part of a network redesign.