AXT1800 Chromecast Discovery Fails

jimv · 2022-08-11T16:09:41.548Z

My Wi-Fi devices don’t discover my Chromecast anymore. It uses mDNS to announce its services. What’s strange is that I see other services from other devices via mDNS, like _raop._tcp. for AirTunes, and that works. It’s just the Chromecast that’s not there (no _googlecast._tcp.). Makes me suspect mDNS services are filtered somewhere, but I can’t where that might be.

I verified that the Chromecast works normally on a different router. My AXT1800 uses WPA2 and 11w is disabled. The Chromecast connects normally and I can ping it.

I don’t need any special filtering or routing for multicast because this is a very small network. IGMP snooping is off, and multicast support is checked for wlan0 and br-lan.

I recently upgraded to 4.0.1 firmware, and I think it worked on 4.0 (could be wrong).

Any ideas?

xize11 · 2022-08-11T17:28:25.297Z

I’m not entirely sure, but I did noticed a standard installed package called avahi on the axt1800.

From what I could read about this package avahi allows advanced routing for mdns/chromecast between subnets.

Upon more searching it seems you have to enable
enable-reflector=yes

But since you use no difficult setup (i.e lan shared with wifi) I think this package is not needed, have you checked if ap isolation is off in luci in your wireless network?

Also maybe multicast has to be on, on your br-lan bridge since mdns litterly means multicast dns, you can test this by going to interfaces>devices tab>edit br-lan.

Full conversation on openwrt: https://forum.openwrt.org/t/bridging-mdns-between-networks/113840 I just learned something about avahi although I have not much knowledge for chromecast.

jimv · 2022-08-11T18:38:33.778Z

Yeah, I’ve been playing with Avahi to see if it would help. It shouldn’t be necessary as the wlan/lan is all a single subnet. avahi-browse does show the mDNS service from the Chromecast, so it is reaching the router but not getting sent back out the radio as a multicast frame.

Client isolation is disabled.

jimv · 2022-08-11T19:57:02.321Z

OK, I figured out what I did. In my wireless config I had option proxy_arp ‘1’ set, which must have caused an issue with multicast forwarding. When I removed it, everything started behaving as expected.

alzhao · 2022-08-12T08:57:04.123Z

jimv:

had option proxy_arp ‘1’ set

Did you add this for purpose? The default config does not have this.

jimv · 2022-08-12T12:53:24.834Z

I was just exploring what other hostapd options I could add to the config that would work. With option proxy_arp ‘1’ set, it does flip the proxy arp bit in the beacon extended capabilities IE. I also found a few 11ax things that OpenWRT hasn’t documented that will also at least alter the beacon IE’s:

option he_mu_beamformer ‘0/1’
option he_bss_color ‘’