AXT1800 Chromecast Discovery Fails

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?

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

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: I just learned something about avahi although I have not much knowledge for chromecast.

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.

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.


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

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 ‘’

1 Like