Chromebook failing to find Roon Server

Core Machine (Operating system/System info/Roon build number)

Windows 10 Pro

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Google Nest WiFi

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Simaudio Moon 780D DAC

Description Of Issue

Chromebook can’t find Roon Server (Windows PC). Android phone and iPad clients have no issues connecting. I have verified network config, and scanned for server using its IP address. Are there known issues using Chromebooks? This is my first attempt. Thanks!

This is because of the network sandboxing ChromeOS does to Android apps, combined with Roon stupidly implementing their own service discovery instead of using mDNS.

Workaround is to hit the “help” button and type the IP address of the Roon Core in. After that, Roon will remember the IP and should reconnect automatically on future start. (I can confirm this works on my own Pixel Slate.)

1 Like

I can also confirm that this also works on my Chromebook.

Regards

Mike

I’ve tried this and it doesn’t seem to find it. Any other troubleshooting ideas on searching by IP address? Seems like it should find it. I’m not very familiar with ChromeOS, so I don’t know of many troubleshooting avenues. Thanks for your assistance!

That makes no sense, mDNS also relies on IP multicast that is the issue (in some cases) with Roon.

1 Like

Yes. But the difference is, the OS provides the mDNS daemon and automatically makes it work in the sandboxed network that Android apps run in under ChromeOS. Whereas direct use of multicast in that sandbox will only ever see other Android apps running on the same physical machine – multicast to the main network is impossible.

mDNS is also way more reliable for service discovery under normal Android as well, for the same reason of being an OS daemon that is immune to app doze.

Don’t understand how endpoint changes would make a reliable positive difference to buggy IGMP implementations in switches and routers, but this is drifting too far from the original topic. And of course adding yet another background OS process in Android is not ideal for security and power management reasons.

  1. mDNS uses one of the multicast addresses which are in the “always flood” range (this range set up so things like AUTO-RP and other core multicast services always work, since there would otherwise be a chicken-and-egg situation with IGMP snooping). The group address used by Roon is (correctly) not within this range reserved by IANA, so it is subject to IGMP snooping and thus the problems introduced by “half-managed” switching environments.

  2. The mDNS process is already there. It’s part of the OS’ core services. It is always running. It is not a case of ‘adding another service’.

And on ChromeOS, Roon’s custom multicast group will never leave the sandbox VLAN ChromeOS creates for the Android VM runtime. Whereas the mDNS server runs as part of ChromeOS and the Android runtime provides API hooks back into it. Hence why Android apps that use mDNS for discovery work correctly on ChromeOS, while Roon discovery does not.

(mDNS server is also a core part of Apple iOS and OS X, Linux, even WIndows 10 has a MS-provided mDNS server in the core OS now – It’s not just Android/ChromeOS.)

1 Like

Android uses DNS-SD, not mDNS, but I get your point, since the two are compatible.

Timothy,

Hit “help” button and try IP address 255.255.255.255

1 Like

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