I recently built a Raspberry Pi (DietPi) as a Roon Bridge, connected to a Chord Mojo as a DAC.
On my home network, it works like a charm (running a local core on my MacBook Pro).
When I installed the Pi in my office, system comes up fine (ping/ssh/etc all work great), says Roon Bridge is running, but I can not see it from my MacBook Pro in Audio Setup.
I suspect our work network is doing something to Roon traffic, but I can’t find any details on what ports/protocols Roon uses to be able to diagnose the problem.
Any thoughts/pointers that folks can offer on debugging network connectivity issues to a Roon Bridge?
I would check to see if you work environment has a managed switch; they can cause issues depending on how they are configured with the multicast that Roon uses.
Hi @Ray_Ghanbari ---- Thank you for the feedback! My feeling is that this is related to the companies’ security protocols associated with their network configuration. I am not sure if you are able to confirm this or not, but can you verify the following for me:
Are there any active firewalls?
Are you aware of any network related software that the company may be making use of (VPN, VOIP etc. )?
We do run the usual big company security controls on our network (forgive me for not sharing details, for obvious reasons). Is there a resource that describes the kind of multicast that Roon uses/requires? I can wokr on my side to see if and how to bridge the gap
I can confirm from logs that the issue is multicast being blocked on work network. Is it possible to configure a Roon Core to directly connect to a Roon Bridge (via IP) and bypass the multicast discovery? Does the actually streaming happen over multicast?
Ray
03/09 12:35:59 Trace: [raatmanager] initialized
03/09 12:35:59 Info: [RAATServer] running RAAT__manager
03/09 12:35:59 Trace: [raatmanager] starting discovery
03/09 12:35:59 Trace: [discovery] starting
03/09 12:35:59 Info: [discovery] [iface:127.0.0.1] multicast recv socket is bound to 0.0.0.0:9003
03/09 12:35:59 Info: [discovery] [iface:127.0.0.1] multicast send socket is bound to 0.0.0.0:44814
03/09 12:35:59 Info: [discovery] unicast socket is bound to 0.0.0.0:9003
03/09 12:35:59 Trace: [raatmanager] starting server
03/09 12:35:59 Info: [jsonserver] listening on port 33672
03/09 12:35:59 Trace: [raatmanager] announcing
03/09 12:35:59 Warn: [discovery] got send failure: network is unreachable
03/09 12:35:59 Debug: [discovery] broadcast op is complete
03/09 12:36:03 Trace: [RAATServer] network reachability changed, refreshing discovery
03/09 12:36:03 Trace: [raatmanager] updating network interfaces
03/09 12:36:03 Trace: [discovery] stopping
03/09 12:36:03 Trace: closing multicast
03/09 12:36:03 Trace: [discovery] closing unicast send socket
03/09 12:36:03 Trace: [discovery] closing unicast recv socket
03/09 12:36:03 Trace: [discovery] starting
03/09 12:36:03 Info: [discovery] [iface:127.0.0.1] multicast recv socket is bound to 0.0.0.0:9003
03/09 12:36:03 Info: [discovery] [iface:127.0.0.1] multicast send socket is bound to 0.0.0.0:39322
03/09 12:36:03 Info: [discovery] [iface:10.0.4.125] multicast recv socket is bound to 0.0.0.0:9003
03/09 12:36:03 Info: [discovery] [iface:10.0.4.125] multicast send socket is bound to 0.0.0.0:32768
03/09 12:36:03 Info: [discovery] unicast socket is bound to 0.0.0.0:9003
03/09 12:36:03 Trace: [raatmanager] announcing
03/09 12:36:03 Trace: [raatmanager] refreshing platform
03/09 12:36:07 Debug: [discovery] broadcast op is complete
On a Class-C subnet discovery can work via unicast/brute force or broadcast too. But if you’re on a bigger network (and you probably are), multicast is the only way right now.
Thank you @brian that’s good to know. I’m playing with UDP to TCP tunnels to get the discoverability working. Still shaky (because of my shaky unix networking skills), but I’ll post if I find a config that works (I’m playing with netcat and socat tunnels)
To followup on this topic, I was unsuccessful using tunneling to bridge UDP to TCP (and back) on our work network. I could get pieces to work, but never got the whole thing to work.
As a work around, I installed squeezelite on my RPi, and configured it to bind to the Roon Core on my laptop via IP (squeezelite -s Core IP Address) With Squeezebox support “on” on my Roon Core, I’m able to connect to my RPi as a Roon end point now
Hopefully, RoonBridge will get the capability to be configured to a Roon Core IP address as well, and I’ll be able to keep things “in the family”
I am having the same difficulty. Roon core runs on my media server which is on a different subnet in my house than a PC in my office. Roon installed on that PC in my office can see the Core only if I specify the IP. However, the Core does not see the Roon Bridge installed on that office PC, so even though Roon is installed on that PC it can not play music from the Core.