Wie Chromecast über Subnetze funktioniert

4893
Adam Mills

Ich weiß, dass Google sagt, dass es nicht unterstützt wird. Hat jemand einen Chromecast, um mit einem Client in einem anderen Subnetz zu sprechen? Ich habe einen OpenWRT-Router, der mit dem Router meines Internetanbieters (übergeordneter Router) verbunden ist. Das OpenWRT-Netzwerk ist ein anderes Subnetz und behandelt DHCP usw. OpenWRT-Netzwerk (192.168.1.0/24) und übergeordnetes Netzwerk (192.168.11.0/24)

Der Chromecast befindet sich im übergeordneten Netzwerk. Ich möchte, dass Clients im OpenWRT-Netzwerk den Chromecast verwenden.

Ich habe igmp_snooping aktiviert und igmpproxy und avahi-daemon im Reflektormodus ausgeführt. Ich kann Chromecast im Bonjour Explorer (von einem Computer im OpenWRT-Netzwerk) sehen, aber die Chromecast-App stellt keine Verbindung her.

Ich habe auch versucht, die TTL auf dem OpenWRT-Router zu erhöhen

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 

Mit Wireshark kann ich sehen, dass der Chromecast und der Computer über Subnetze sprechen ... aber er verbindet sich nicht.

Ich kann auch den Chromecast über das untergeordnete Netzwerk anpingen.

Hat das jemand gemacht? Irgendwelche Hinweise?

8

2 Antworten auf die Frage

1
NigelB

Soweit ich das Problem feststellen kann, ist das einzige Problem, das verhindert, dass Chromecasts aus anderen Subnetzen verwendet wird, eine Erkennung, die von Multicast-UPNP-Paketen behandelt wird, die leider eine TTL von 1 haben. Statt dass mein Router das übliche Multicast ausführt shenanigans und das Anpassen der TTL, wie Sie vorschlagen, habe ich ein Python-Skript geschrieben, um meinen Chromecast im anderen Subnetz anzukündigen. Es ist auf Github verfügbar .

0
Rowan Hawkins

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.