Как заставить Chromecast работать в подсетях

4731
Adam Mills

Я знаю, что Google говорит, что это не поддерживается. У кого-нибудь есть Chromecast для общения с клиентом в другой подсети? У меня есть маршрутизатор OpenWRT, подключенный к маршрутизатору моего интернет-провайдера (родительский маршрутизатор). Сеть OpenWRT является другой подсетью и обрабатывает DHCP и т. Д. Сеть OpenWRT (192.168.1.0/24) и родительская сеть (192.168.11.0/24)

Chromecast находится в родительской сети, я хочу, чтобы клиенты в сети OpenWRT использовали Chromecast.

Я включил igmp_snooping, запустив igmpproxy и avahi-daemon в режиме отражателя. Я вижу Chromecast в Bonjour Explorer (с компьютера в сети OpenWRT), но приложение Chromecast не подключается.

Я также попытался увеличить TTL на маршрутизаторе OpenWRT

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

Используя wireshark, я вижу, что chromecast и компьютер разговаривают через подсети ... но он все равно не подключается.

Я также могу пропинговать Chromecast из дочерней сети.

Кто-нибудь сделал это? Есть указатели?

8

2 ответа на вопрос

1
NigelB

Насколько я могу сказать, единственная проблема, препятствующая использованию Chromecasts из других подсетей, заключается в обнаружении, которое обрабатывается многоадресными пакетами UPNP, которые, к сожалению, имеют TTL 1. Вместо того, чтобы мой маршрутизатор делал все обычные многоадресные рассылки. shenanigans и настройку TTL, как вы предлагаете, я написал скрипт на python для рекламы своего Chromecast в другой подсети. Это доступно на github .

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.

Похожие вопросы