Premise: Windows and macOS machines sitting on the same subnet; Chromecast sitting on a different subnet.
Windows: It takes two or sometimes ten unsuccessful searches for the Chrome browser to discover the Chromecast device.
MacOS: Chromecast is instantly recognized.
Why the difference?
I doubt this is an OpenWrt issue but go ahead and
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
And, also, run ipconfig in command prompt, copy and paste in your reply.
Maybe the windows firewall. Have you tried disabling the firewall?
I also doubt it is strictly an OpenWRT issue. I think it's a compatibility issue between Windows and the avahi-daemon. Or maybe Apple's own Bonjour service implements mDNS in a more efficient manner?
I wonder though what causes the hiccups between the Windows and the Avahi reflector. What could I try to improve reliability? As I said, it eventually starts working i.e. the Chrome browser does eventually discover the Chromecast device. The problem is that it is not reliable.
One clue would be that the Avahi Reflector only repeats two of the four mDNS packets sent by the Chromecast device.
Tried it! I turned off Windows Firewall. No results. Aditionaly, when the Windows machine and the Chromecast share the subnet, they instantly become visible to one another. (regardless of Windows Firewall)
It was just a guess... worth the experiment to rule that out as a possibility. Sorry it didn't help.
Yep! Thank you for the tip.
I'm addressing this problem on a clean OpenWRT install. Created two VLAN subnets and placed them under the same firewall zone. The avahi-daemon is up and running with enable-reflector=yes.
One thing to note is that macOS routinely sends queries to the multicast IP address (224.0.0.251 port 5353).
For Windows, it takes something like the Chrome browser to initiate a query to the multicast IP address. Otherwise, Windows itself is completely silent.
In the picture above you can see:
violet: Chromecast on 10.20.23.225, constantly sending queries to 224.0.0.251
light blue: avahi-daemon on 10.20.23.1 repeating macOS routine announcements from a different subnet
The avahi-daemon stuck on DNS query retransmission. Another clue why Windows and the Chrome browser is failing to recognize Chromecast devices available on other subnets.
Solved!
Add cache-entries-max=0 to your /etc/avahi/avahi-daemon.conf file and it will reflect chromecast symmetrically across multiple subnets. All it takes to increase reliability from 10% to 100% on Windows machines. macOS does not care: works either way!
[server]
#host-name=foo
#domain-name=local
use-ipv4=yes
use-ipv6=yes
cache-entries-max=0
check-response-ttl=no
use-iff-running=no
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.