Roon Bridge Suspicious Process?

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

Apple iMac (Retina 5K, 27-inch, 2017) [4.2 GHz Core i7, 48GB Memory, 1TB SSD + 5TB External HD); macOS Mojave 10.14.3.

Roon Version: 1.6 (Build 401)
Roon Bridge: 1.0 (Build 169)

Library stored on External 5TB HD (attached to iMac via USB3), 17,500 tracks, Qobuz (Sublime+)

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

UniFi Security Gateway 3P Router, Unifi Switch 8 POE-150W, UniFi Switch 8 and UniFi AP-AC-Pro for Wi-Fi.

Audio Devices (Specify connection type - USB/HDMI/ect.)

Yamaha NX500 speakers (directly attached to iMac via USB), Bluesound Pulse Mini 2i (Wi-Fi - 5GHz), Bluesound Pulse Mini 2i (Wi-Fi - 5GHz), Bluesound Pulse Flex 2i(Wi-Fi - 5GHz), Bluesound Node 2i (Ethernet)

Description Of Issue

I installed Roon Bridge on my macBook Pro (13-inch, 2017) [3.5 GHz Intel Core i7, 16GB Memory, 1TB SSD].

I use Little Snitch firewall and when I start Roon Bridge I get a “Suspicious Process!” alert from Little Snitch that Roon Bridge is trying to connect to 104.196.137.72 and when I deny that I get the same alert from Little Snitch that Roon Bridge is trying to connect to 34.73.154.2 which I also deny.

Little Snitch says that: “the process has no code signature. This means the developer is anonymous and their real-life identity cannot be determined.”

Why is Roon Bridge trying to connect to these IP addresses and should I be worried that there is no code signature.

Even though I have denied access to these IP addresses, the Roon Bridge still appears to work.

Thanks for any help. :smiley:

Not sure if you should be worried - but it’s a known thing that not the entire Macos app contents is signed, see here for instance: RAATServer and Roon MacOS applications "Missing Code Signature"

Up to now there’s no official statement on why that is like it is nor has there been any change the last few releases.

That’s something for Roonlabs to explain, too. What it could be - you might see this in the “About” box - is a place to look for updates. Roon does this regularly. If “About” says “There was an error checking for an update” for the Bridge device it would indicate that those IPs point to update locations.

@anon47919701 - thanks for the link; should have done a search - lesson learnt. :flushed:

Looks like the main Roon App running on my iMac is also accessing at least one of these IP addresses. :confused:

Hmm, I wouldn’t think you’d want to deny those addresses. Roon is probably accessing them to do some housekeeping, get database info, etc.

If anything untoward happens, it’s probably because of those denials.

BTW - I’ve read other users of Snitch complaining about other things. A forum search will show up many such instances.

I’m using Little Snitch for a couple of years now and haven’t had problems with it. It goes without saying that it’s helpful to keep in mind that blocking an app from communicating over the internet may impact the app – or not. :sunglasses: For Roon Bridges I found that once set up internet connectivity is not needed. For a core things are different - even so I generally dislike it when an application uses IP addresses instead of FQDNs.

What those two IPs – belonging to Google and used by its cloud service, or so whois tools say – are for I have no idea.

Roon is a service–the parts of Roon running on your hardware work together with our cloud services to do their job in many ways. If you block this communication, aspects of the product may stop working. Obviously it’s your machine and you are free click that button, but be aware that whacking random communication channels between components of Roon may break stuff in ways that cause your installation to become difficult to support.

Little Snitch isn’t very smart. It reports on normal things happening on your system and leaves it up to you to decide what is appropriate or not. There is nothing suspicious about the connections in my view. The lack of code signature is something we should look into (@vova, please track this).

What those two IPs – belonging to Google and used by its cloud service, or so whois tools say – are for I have no idea.

Those IPs are allocated to Google because like most companies, we rent infrastructure from large platform providers. We use Google Cloud Platform, Amazon Web Services, and Digital Ocean for different parts of our cloud infrastructure. Those connections are terminating at our backend services.

even so I generally dislike it when an application uses IP addresses instead of FQDNs.

Me too…but we aren’t doing the bad thing you imply–there are no IP addresses baked into the Roon source code, only host names. I guess Little Snitch is failing to translate them properly for some reason.

@brian thanks joining the conversation. :slight_smile:

I don’t think so - at least one of that IPs occurs regularly in the logs of my ROCK core - and there’s no Snitch fiddling with things on the NUC:

03/26 00:58:20 Trace: Successful POST response from https://push.roonlabs.com/push/1/connect
03/26 00:58:20 Trace: [push] connecting to 34.73.154.2:9200
03/26 00:58:20 Trace: [push] connected

I really have no idea what happens here and that’s mostly fine – and I’m not implying it’s anything bad. :wink:

BTW I agree that Little Snitch - probably like most consumer oriented firewall applications - is not too smart and blocking stuff always goes against the developer’s intention - and may break things for the user. Only sometimes apps do not really need to talk as much as they do and then a firewall can help a little. Again - I’m not implying that this is necessary with Roon, it’s a more general observation.

That stuff like Little Snitch is out there has a reason and usually it’s not too hard to provide the information on what an app needs so it can live with a desktop firewall just fine. While I do understand that supporting this has limits I always cringe a little when it reads somewhere: turn your firewall off. It’s more effort to explain what needs to be open (and why), but maybe it’s worth it. Just my opinion.

That IP is obtained from a load balancing component on our backend that does not speak the DNS protocol. In a normal situation, I think Little Snitch translates IP->Host using the results of past DNS sniffing, but that wouldn’t work here because this IP never appeared in a DNS exchange. Still not baked into the code :slight_smile:

I’m not about telling people to turn off their firewall except as a temporary troubleshooting step. We perform QA testing with the standard win/mac firewalls turned on.

Little Snitch is deliberately intrusive. It is designed to err on the side of encouraging distress over benign behavior because the whole point of the product is to flag everything by default and let you decide what is OK. If we failed to work with the win/mac firewalls I’d consider it a problem, but Little Snitch was designed to over-report…so I am not very distressed that it’s found something to complain about.

I kind of understand what makes this interaction weird enough to get flagged, but at the same time, we aren’t doing anything nefarious by talking to our own servers, so :man_shrugging:

It’s the point of Little Snitch, I’d say. Agreed, it’s not going well with the flow and if things don’t work because of it it’s not a Roonlabs problem.

Asking what a network connection is needed for is nevertheless OK, I’d say. You explained a bit / confirmed it’s part of what Roon needs - so all’s good. :slight_smile:

@brian Thanks for the explanation on the IP address usage.

I guess the thing that worried me most was that the code was unsigned and was worried in case there was malware afoot.

As a footnote: I am a Sublime+ Qobuz user and when they emailed me about how their service was now integrated with Roon, I had to give Roon a try (using the Qobuz extended trial). I am now signed up as a happy lifetime user. :grinning:

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