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

Installing and Using OpenWrt
1

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's 4G connection via USB tethering.

A large reason for carrying the WT3020 with me is that I also take a Chromecast, and having a travel router makes it easier to have my own private LAN that connects easily between Android phone and Chromecast.

My trouble is that when I connect to the hotel WiFi with a WISP setup, the Chromecast works fine initially, and I can see and cast to it using my phone on the same LAN subnet (192.168.8.x).

However, after some time, the Chromecast remains visible under "Interfaces>Wireless>Associated Stations" but it disappears from any apps (YouTube, Netflix etc.) as a target to cast to, and the Google Home app says that it can't be found on my WiFi network. All other devices on the internal LAN (192.168.8.x) still have internet access. If I login to Luci and go to "Interfaces" then restart LAN, the Chromecast reappears as a cast target and in the Google Home app, but only for a while until it disappears again.

I think this might have something to do with mDNS/Multicast/IGMP Snooping, but to be perfectly honest, after searching every Chromecast related thread on the OpenWRT forums, as well as a lot of Googling and reading the OpenWRT wiki, I'm more confused than ever.

Below are some configs and logs. Anybody have a clue as to why this might be happening?

/etc/config/network 
config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd06:a3fc:660f::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option ipaddr '192.168.8.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config device 'lan_dev'
	option name 'eth0.1'
	option macaddr '00:00:00:00:00:00'

config interface 'wan'
	option ifname 'eth0.2'
	option proto 'dhcp'
	option type 'bridge'
	option peerdns '0'
	option dns '192.71.245.208 51.15.98.97 172.104.136.243 193.183.98.66'

config device 'wan_dev'
	option name 'eth0.2'
	option macaddr '00:00:00:00:00:00'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '4 6t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '0 6t'

config interface 'trm_wwan'
	option proto 'dhcp'
	option peerdns '0'
	option dns '192.71.245.208 51.15.98.97 172.104.136.243 193.183.98.66'

config interface 'USBTethering'
	option proto 'dhcp'
	option ifname 'usb0'
	option peerdns '0'
	option dns '192.71.245.208 51.15.98.97 172.104.136.243 193.183.98.66'
/etc/config/wireless 
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'

config wifi-iface
	option network 'trm_wwan'
	option device 'radio0'
	option mode 'sta'
	option ssid 'SSID'
	option encryption 'psk-mixed'
	option key 'PASSWORD'
	option disabled '1'

config wifi-iface
	option device 'radio0'
	option mode 'ap'
	option ssid 'SSID'
	option network 'lan'
	option encryption 'psk2+ccmp'
	option key 'PASSWORD'

config wifi-iface
	option network 'trm_wwan'
	option device 'radio0'
	option mode 'sta'
	option ssid 'SSID'
	option encryption 'psk'
	option key 'PASSWORD'
	option disabled '0'
/etc/config/firewall 
config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option syn_flood '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option device 'tun0'
	option network 'wan wan6 trm_wwan wwan USBTethering'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'

Kernel log:

https://pastebin.com/zLNmA2r3

System log:

https://pastebin.com/wJk0N5Ps

3

A thought I've had... is this something to do with the fact that the TTL is set to 1 on SSDP packets to allow Chromecast discovery, and therefore these packets are being dropped on the WAN subnet that I'm WISPing from before reaching my LAN (192.168.8.x), as detailed here?

https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1061046

Does this mean adding iptables -A PREROUTING -t mangle -p udp --dport 1900 -j TTL --ttl-inc 1 to my custom firewall rules may fix the issue?

NB - Just to be clear, unlike the person from that thread, I have no desire for people in the upstream WAN subnet to be able to see and cast to my Chromecast, in fact quite the opposite. I merely want to be able to discover the Chromecast in the LAN created downstream of the WISP (subnet 192.168.8.x).

Obviously ideally I would just have everything under one subnet, but that's exactly the opposite of what I want here as I have no control of the upstream network as it's a hotel/guest network and I in fact want to be totally firewalled from it otherwise.

4

Solution was to upgrade to the 19.07 SNAPSHOT with Luci and enable IGMP Snooping and disable legacy 802.11b rates as I discovered in this thread:

Relevant Wiki links:

1 Like
5

Not fixed unfortunately, just delayed:

Trying a Gl.iNet AR300M instead to see if it handles things more consistently.

6

Yup, AR300M is solid as a rock under the same setup:

Can't mark this as "solved" really. It's an issue for some people depending on the device used I guess...

7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.