RAAT discovery issue

Roon Core running 1.7 (build 555) stable on ubuntu

Windows 10 PC running Roon 1.7 (build 555) stable (64bit)

They are on different subnets for security (core is out on wifi so it can access Sonos - I wrestled with Sonos discovery for a while).

PC can access roon - I’ve got that discovery worked out and can access the albums just fine, but the Roon core can’t find the PC’s RAAT server to access any audio devices. I’ve punched holes in the windows firewall for RAAT server and have been doing packet captures to diagnose the problem, but no luck.

I have 6 days left in my 2 week trial - setting this up shouldn’t be this hard!

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

heh… I wish I got this far. I of course have onboard audio on the PC - an Oppo HA1 driving headphones and external speakers.

Description Of Issue

Can anybody share the packet flow needed for audio device discovery? I certainly see alot of traffic between my pc and the core on 9101 after 9001 discovery. Is is possible to run just RAAT without the roon UI on the PC so I can eliminate the traffic of the UI and focus on RAAT exchanges?

This is not supported. See also:



1 Like

I’m presuming you are doing some form of bridging between the subnets as roon requires a flat contiguous range as it is a broadcast protocol.
You can install roon server headless and control from a client.

I’m comfortable adding rules for particular ports and addresses, but making everything open is a terrible practice. I can also repeat udp broadcasts to aid in discovery (though many impls lock themselves down to the local subnet because people are fools and allow upnp/etc packets in from the outside).

The Roon UI does a nice job allowing you to bypass discovery by manually inputting the core’s addr, is there a way to do the reverse and input addr for RAAT servers?

I was looking to go further - run RAAT headless with a headless server and potentially drive from a tablet/phone. Really I don’t even need to drive, I just want to watch the packets between core and RAAT without the volumes of UI traffic adding noise.

Looking at RAATServer_log.txt, I can see the RAATServer is listening on port 9003. It also says it’st jsonserver is listening on 50784. That’s a new one for me - do we need to support traffic out there?

I can see traffic between my RAAT machine and my core on 9003.

I guess the remaining question (beyond the manual setting I’ve already posed) is will the Roon software intentionally fail because it’s not on the same subnet even if traffic could and does flow? I’ve found several discovery proto impls that do that: exchange all the info it needs but not ack the device because it fails a subnet check.

If your internal/private network is properly secured, there is no need to separate your Roon Core, Roon Control and Endpoints into a separate network. If all Roon related devices (Core, Control, Endpoint) are separated out on the same network, there shouldn’t be a problem too.

Having Roon devices on different networks is not supported. If you wish to try to make this work, it’s better to move on to the #tinkering section of the forum. Please have a look into this section and/or use the search function to find previous threads about this. I actually can’t remember of any thread where a user posted a successful recipe to achieve it.

Note: Roon discovery uses multicast not broadcast.

See also:

Hey BlackJack,

I think it comes down to IOT security and Wifi security. Wifi is up 24/7, it expands beyond my physical walls and it’s notoriously vulnerable to attacks. It’s also the home of my TV, my light switches and every other random wifi “tool” (my range hood has wifi!) which are terribly supported and not designed with security in mind. I’m not going to put my servers and personal computer (with bank info and financial info) on the same network as those two security problems.

Thanks for the tinkering redirect!


You will need to look into, MDNS, multicast routing and PIM etc if you want this to work. So this will be dependant on how configurable your gear is. This type of situation is unsupported for good reason it would cause all manor of headaches for the team to support. No streaming system I know of supports cross subnet Discovery without some network tinkering. Personally I find all this paranoia a little ott.

1 Like

I’ve moved it to tinkering…

Yeah, I’ve been looking into this stuff. AFAICT roon doesn’t use mdns for core<->RAATServer discovery. It uses 9003 multicasts and then ~9103 udp to share info. It looks like all the packets make it both ways but the core never acknowledges the presence of the RAATServer audio devices.

I need to try another test after work getting good data on a same-subnet success case for more comparisons. Ideally this would be documented somewhere rather than needing to be reverse engineered, but as a software dev I know the priority of docs for most developers.

I’m using a Ubiquiti EdgeRouter for this (with the 3rd party UDP reflector) and it seems pretty configurable. My concern is despite supporting all the traffic, if the core gets info from a RAATServer that says it’s on a different subnet it could still throw out the RAATServer.

I wouldn’t be at all surprised.

My Roon core, wired, is on the “wireless” network. You can have a secure network away from your personal computer that can also include wired devices. This is how I’ve addressed your concerns.

I attempted the “routed Roon” and decided the proper thing to do was to secure a “devices” network where all my wireless random devices live and use that for Roon. That was a much more direct path and I’m more secure for it. My personal computers cannot access the Roon server but I don’t really trust Roon security any more than my random devices anyway so I wouldn’t want it on the same network as my personal computer.

Sorry I’m not solving your 2 network problem but I would encourage you, for your own sanity and time, to just put the Core on the “wireless” network and enjoy it.

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