Manual override of broadcasts-based autodiscovery

Feedback Feature Suggestions
1

Hello,

I am in a situation where I have to remotely manage and maintain a few remote Roon installations. This number is also likely to exponentially grow in the near future.

The cores and most of the bridges are all Linux based and I can perform about 90% of my tasks using SSH and the command line.
There are, however, quite a few things that require the Room Remote, and, there, I have to resort to TeamViewer or other remote desktop methods, all involving the “customer’s” hands-on involvement.

I know that the roadmap includes a remote capability. But there is no date attached to it and little information about its real capabilities once delivered. While I’d like to hold my breath, it looks like something that is potentially dangerous for my health!

I’ve tried multiple solutions like VNC servers, X through SSH, but those fail by lack of hardware 3D rendering (the Remote GUI requires it for performance), or VPN solutions.

VPN solutions could be promising, especially when the gateway is installed on the Core machine, making the control device part of the same layer 3 network. But it only partially work.
I get a success with my home Core, as the Remote apparently has some memory of the last core it connected to and can directly access it. But there is no way of connecting to a different Core, as discovery is automatic and based on broadcasts that are only rarely passed over point to point VPN links (I’ve tried multiple VPN solutions and settled on WireGuard for its security, ease of deployment, performance and platforms support).

So, while I understand that autodiscovery using broadcasts is a very good solution for the masses, it’s automagic and the typical user is very happy, it would be good to have a manual override somewhere, a way to point the Remote to a Core’s IP address, and take it from there, even if it is not an obvious big button in the GUI.

I understand that it is a very fringe use case, but it is one that is important to integrators, also a license sales vector, if only a bit marginal.

On a side note, if the mobile app could be made to not base its discovery efforts on the use of Wi-Fi, it would be good too.

2

This popped up for me because you mentioned roon and wireguard. There are a number of people trying to hack Roon into a remote player, like via phones while away from home. From what I’ve seen, and failed with, a TUN type VPN connection might be the ticket to getting remote Roon access. But what about wireguard?

3

As I said above, Roon works by heavily relying on broadcasts. They are issued at layer 3, but are mainly a layer 2 issue, as they are not routed.

That makes Layer 2/bridging VPNs ideal for Roon. But they are a bit iffy and very inefficient, thus quite unpopular in general, and badly supported, especially on mobile platforms (including for security reasons).

Wireguard is a layer 3 VPN. It establishes its own layer 3 link and everything else becomes normal routing.
You can partially achieve Roon functionality by hosting Roon’s core and the Wireguard end-point on the same machine. The VPN is then directly linked, Roon sees the interface and will play along.
However, Roon bridges discovery is only based on broadcasts. You would think that it’s fine, the 2 VPN endpoints are on the same network as the Roon Core, they will see each other. But no, Wireguard made a design decision of declaring its links as point to point, meaning that, at layer 3, there is room for only 2 addresses, nothing is available for broadcasts, which are blocked.

Wireguard will allow you to see the core, control it, perform maintenance on it, even play music on the bridges on the other side, but the core will not see your bridge on your side of the VPN (remember, no broadcasts, so no discovery) so it won’t be able to play music to your remote device. There is no manual override where you can indicate to Roon, btw, there is a bridge right here…

So, I’m happy to be able to perform remote maintenance on clients’ Roon installs, but that’s where it stops.

Either Wireguard needs to start providing an option to open up its links to broadcasts (unlikely), or Roon need to provide a manual override (unlikely)…

Or we need Roon to deliver on its announced remote play capability. It’s been a while since we heard from that one, though!

Then there is the side issue where the phone app will not even make any discovery effort if it discovers that Wi-Fi is unusable. If you are on mobile data, with a VPN on, Roon will not bulge!

1 Like
4

For what it is worth: I got a little bit more joy out of ZeroTier installed on the same machine as the Core. It does al the above for me and also allows playback on the ‘remote’ endpoint, including via mobile data. There are threads where others also report results using ZeroTier. Not sure if it would solve the problem of discovery and connection of ‘fresh’ remotes, previously unknown to the core.

Checked just now, and it still works (for ‘known’ remotes), both with wifi (on a separate network) and over a sub-optimal 4G connection.

Having said this, there are caveats .It seems somewhat prone to interruptions - especially on my less than optimal 4G connection - but even with the remote connected to a reasonably fast network. The less than 10Mb/s uplink from the network on which my core resides is a good candidate bottleneck.

I found it interesting conceptually, and much easier to configure than VPN options tried earlier. But given the above not reliable enough to make part of my on-the-go setup. Things may be different with a faster uplink from the ‘Core’ network and/or 5G mobile.

5

thank you @ToneDeaf and @Nicolas_Will . Dang, still sounds like a goat-rope. I’m just going to continue lurking around here being a squeaky wheel for remote library access on my phone! I know it’s feasible - Roon just need to get 'er dun, then take my money.

6

I have the same issues running wireguard inside a Mikrotik router. I can control Roon but not stream to the remote device (Android smartphone). It would be nice to have a L3 discover that one could enable for either a certain IP subnet. But I guess that this has been a design decision made by Roon so that it would be difficult to share the same Roon core over L3 networks. :slight_smile:
I would appreciate if I could choose which interface is allowed to support L3 discovery (I have 4 different VLAN networks connected to same Roon core running in Docker).
Native support for ZeroTier is finally coming to Mikrotik router (ROS 7.x) so that we could bridge L2 traffic directly in a bridge within a Mikrotik router. :slight_smile:

7

Nothing has happend on that front. Even if I’m running a mDNS repeater between subnets I’m not able to make the remote Roon bridge discoverable to the Roon core. I hope that Roon would consider to either release an ARC version for Linux that can be remotely controlled from any other Roon client/app.