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).
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: https://forum.openwrt.org/t/bridging-mdns-between-networks/113840 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 ‘’