Just edited this to clarify for non tech folks what the issue is - a deliberate Roon limitation, not some sort of technical hurdle that is difficult to overcome. I find this disheartening, as the audiophile community, of which is a big part of the audience Roon caters to, is used to doing what they can to optimize experiences.
This extends to software; even if it’s unconventional or difficult, enthusiasts will often go the distance to optimize for their situation. It’s disappointing to Roon take this kind of artificially limiting approach.
hi Joselito, did you find any workaround to the deliberate Roon limitation. I am strugling with the same, as many others do…
Unfortunately no. Ironically if you have a remote subnet that you bridge into the subnet that Roon is on (basically using any layer 2 bridging like VPLS, VXLANs, or even something like a Linux gretap interface) will allow you to use it remotely. Still, an overly complex workaround for something that should be natively supported and not intentionally hobbled.
Once you bridged the two subnets together for the first connection to find the core, did you have to keep the two subnets bridged for all future connections? Or can you keep the two subnets separated as long as you have the ability to reach the core?
Appreciate your insight since this is one of the only posts I’ve seen on a potential solution for networking Roon with different subnets.
I haven’t attempted to connect to my Roon Core across subnets, but I have observed that the RAATServer discovery does continue to use the multicast announcements. Looks like they heartbeat between the core and endpoints, so you can’t just connect it the first time and then move it.
That said, Roon appears to listen on ALL network interfaces on the core (at least on a Linux-based system). So if you have multiple networks locally, you could experiment with configuring VLAN interfaces at the OS level and have it participate on each VLAN that you have endpoints. (Again, I haven’t tested this, but my little bit of snooping around suggests that this should work. They join the multicast group on all interfaces on the system (I have a second virtual NIC in my server that bridges to the iDRAC for server health management updates and it creates a listener on this NIC in addition to the main NIC).
In theory, if you installed ZeroTier on the core and the endpoints (e.g., assuming you have OS access to the endpoint, such as with a RPi), you could have any number of physical network hops between the core and the endpoint. And given that Roon pre-buffers several seconds worth of audio, will probably work OK even on not stellar WAN links. But maybe avoid upsampling to DSD512, as that will pump out ~50Mbit/s and that might not be too special over ZeroTier…
I’ve spent the past few days trying to play around with the interfaces between VLANS to support the core. My setup consists of three VLANS: one that contains the core, one with the remotes (my trusted network), and the third with end points (sonos speakers).
I have a MDNS repeater turned on between the VLANS on in the router to support multicasting and I have the router explicitly relaying the the UDP and TCP traffic on ports 9003 and 9100-9200 across all the VLANS, but that hasn’t seemed to help with the discovery process. Are there other things you’ve noticed or suggest testing to help with the discovery process?
I have no idea if this is a fluke, but this started working across subnets. It works even if my mDNS reflector is off, so I’m not sure what’s happening, or if this is a permanent thing. Anyone else got it working?
Well, this is incredibly frustrating. I have two locations connected together by peer-to-peer VPN.
Thought I’d try using Roon on my laptop and just discovered it can’t find my Roon Core presumably presumably because it’s on my other subnet.
That stinks that it’s deliberately disabled
Roon is simply for what networking concerned not on par with the nowadays best-practice network-configs, It can only deal with one single subnet, Core and endpoints should all reside in that, It’s possible to connect from another subnet with roon remote. But music can only stream to endpoints within de subnet the core is connected to. I think it would be a wise thing for the developmentteam to make some efforts to change this because this concept is simply not tenable in many currently used network environments. A substantial flaw for a furthermore quite good product,
Not a flaw it’s a design decision to keep it simple and less support calls using a well known device discovery protocol. It’s hard enough getting it to work reliably on a simple flat network for some users let alone open the can of worms of VLANs. Sonos the leading brand still only works on a single network unless your a network twiddler as it also relies on UDP for discovery. Same goes for Heos and anything using UPnP as it’s discovery method.
AirPlay and Chromecast work across VLANs using mDNS but can run into issues just like anything else it’s all down to the Wi-Fi implementation and software. Some cheaper brands don’t always handle mDNS well though. Most modern systems seem to be good given the prominence of AirPlay in the home but even then some will block wireless to wireless multicasts and result in non discovery, some mesh systems do this. Multicast over wirlesss isn’t particular efficient either as it takes up much more airtime so can make networks more vulnerable to latency have worse performance.
I do agree though that perhaps they should switch to using mDNS for all, if it works well for Apple and Google it must have some merits.
Er no. That’s just rationalization. Have you dumped the packet communication that happens for discovery? It’s not straightforward or simple at all, and doesn’t use any kind of best practices or standard protocol. You in fact can get around the subnet limitation (VLANs have nothing to do with the issue) by brute forcing the UDP packets over a router. But it’s ugly and hacky.
The software devs either implemented their own ugly discovery protocol because they didn’t know better and thought they did (a really bad thing to do in the dev world) or they did it as a form of security through obscurity (which failed, since you can get around it). Either way, it’s clear it was never meant to scale. It’s a terrible blemish on software that’s supposedly for a niche group of power users.
It uses UDP port 9003 solely for discovery of RAAT endpoints and mDNS for others such as AirPlay and Chromecast. It uses a bunch of other UDP and TCP ports for other communications between endpoint and core. UDP will not traverse subnets in any standard network you have to configure it to do so via whatever works on your router etc. When I looked at the traffic once using wireshark nothing shouted out as being bad to me.
UDP won’t traverse subnets? Um… that pretty much says we shouldn’t be putting much stock in your opinion on this subject.
I wouldn’t call it ugly but it’s certainly not pretty.
I also assume some of this is related to the way Core is licensed. This “broadcast domain” limitation works in favor of 1 Core per network.
Yep - it’s pretty much a low-key form of DRM (it makes a single core in a central location accessible by dozens / hundreds of clients spread out across the internet more complex), and I suspect that wasn’t by accident.
It’s multicast (and broadcast) traffic that doesn’t (by default) traverse subnets. The transport layer protocol is irrelevant (and there is plenty of unicast UDP traffic out there).
A lot is blocked yes, but mDNS tends to be allowed pretty easily as all AirPlay and Chromecast use it and they can work fine across subnets. I have all my Chromecasts and AirPlay devices on a separate VLan and phones and remotes on another they all work fine. Roon sees them all as well and is on its own subnet.
Perhaps read my whole sentence rather than quote the bit that suits your agenda. I’m out of here you seem to have a beef I’ll leave you to it.
Never said it wasn’t possible. I run AirPrint, which uses mDNS, across subnets. My point is the router has to be configured to do so. There is a reason why subnets are referred to as broadcast domains.
Indeed same goes for UDP broadcasts they are limited to the same subnet unless you configure a router to not to do so, just a bit more configuring required. UPnP and Sonos also use SSDP on UDP port 1900 which isn’t forwarded by default either.