Linux/RoonBridge stopped working after update to 1.8

Support
1

Roon Core Machine

MacBook Pro (13-inch, 2017)
Processor: 2,3 GHz Intel Core i5
Memory: 8 GB 2133 MHz LPDDR3

Networking Gear & Setup Details

Ubiquity EdgeRouter 6P - all devices wired

Connected Audio Devices

Roon Bridge (1.7/1.8) running on Linux box, kernel 3.8.13 / Busybox

  • No firewall
  • Only ALSA
  • RoonBridge runs as root

Number of Tracks in Library

0 at this time (testing setup only)

Description of Issue

After upgrading RoonBridge from 1.7 to 1.8 it stopped working. It complains about ā€œexception starting raatserver: System.Net.Sockets.SocketException (0x80004005): Connection refusedā€ (see log extracts below). If I run 1.7 again, it is still running fine (in combination with Roon Server 1.8).

In Roon Server, Roon Bridge 1.8 does not show up under Audio. However, I just noticed that it does show in the About section.

Unfortunately the Linux box is running on hardware with proprietary drivers, so I cannot upgrade the kernel or have too much control over it. However, since 1.7 was running fine, Iā€™m hoping this is a minor issue that can be solved.

Does anyone know what is causing this issue or have any pointers on how to further analyse this issue?

Kind regards, Maarten

RoonBridge 1.7 (runs without issues)

./start.sh

Initializing
00:00:00.093 Info: ConnectOrStartAndWaitForExit RAATServer
Not Running (o.)
00:00:03.366 Info: Starting /saDbase/RoonBridge/Bridge/RoonBridgeHelper
Running
Not Running (.o)
00:00:11.330 Info: ConnectOrStartAndWaitForExit RAATServer
Running
Not Running (.o)
00:00:19.355 Info: ConnectOrStartAndWaitForExit RAATServer
Running

RoonBridge 1.8 (RAATServer crashes)

./start.sh

00:00:00.039 Warn: get lock file path: /tmp/.rnbgem0-
00:00:01.437 Trace: [childprocess] using unix child process
Initializing
00:00:01.997 Info: ConnectOrStartAndWaitForExit RAATServer, path: /saDbase/local/bin/RoonBridge/Bridge/RAATServer
00:00:02.373 Info: Starting /saDbase/local/bin/RoonBridge/Bridge/RoonBridgeHelper
Not Running (.o)
00:00:00.198 Warn: get lock file path: /tmp/.rnbhgem0-
Running
00:00:16.625 Warn: exception starting raatserver: System.Net.Sockets.SocketException (0x80004005): Connection refused
at System.Net.Sockets.TcpClientā€¦ctor (System.String hostname, System.Int32 port) [0x0006d] in <4e9ef3a58c61422a955a39996454b958>:0
at Sooloos.RAATServer.ConnectOrStartAndWaitForExit (System.String path, System.String args, System.Action1[T] status, Base.ChildProcess& p) [0x00165] in <b708d17b5bf34394b8a413f43b329e70>:0 Not Running (.o) 00:00:19.029 Info: ConnectOrStartAndWaitForExit RAATServer, path: /saDbase/local/bin/RoonBridge/Bridge/RAATServer Running 00:00:25.068 Warn: exception starting raatserver: System.Net.Sockets.SocketException (0x80004005): Connection refused at System.Net.Sockets.TcpClient..ctor (System.String hostname, System.Int32 port) [0x0006d] in <4e9ef3a58c61422a955a39996454b958>:0 at Sooloos.RAATServer.ConnectOrStartAndWaitForExit (System.String path, System.String args, System.Action1[T] status, Base.ChildProcess& p) [0x00165] in :0
Not Running (.o)
[ā€¦ loop continues]

Log RAATServer running version 1.8
10/04 17:44:59 Info: Starting RAATServer v1.8 (build 814) stable on linuxarmv7hf

1 Like
2

Hi @TheRealMuffin and welcome to the forum.

Looks like the connection attempt gets refused from the Roon Core (MacBook Pro) [SocketException (0x80004005)].

Main change that might cause such an issue was IIRC a change to encrypted connections with Roon 1.8. This could be a firewall issue on the server (read also: McAfee complains right after update to Roon 1.8 (Build 806) stable (64 bit) [Answered] - #3 by dylan) or your Linux box is using outdated (old, unsupported or flawed [generating insecure keys] encryption libraries) or something like that.

You should contact whom ever is responsible for that machine and discuss the issue with them too ā€“ especially if you can rule out problems with the server as the cause. Keep your 1.7 Roon Bridge installation until maybe you can find a solution or the Roon Core refuses unencrypted connections altogether (this might happen at some time in the future).

Disclaimer: Not official support - just another Roon user.

3

Hello @BlackJack Thanks for your response!

Firewall on the server certainly isnā€™t the case. To be 100% sure, I ran RoonBridge 1.8 virtually and that one showed up fine.

The encrypted connection, that could be a thing. However, I just ran ā€œopenssl s_client -connect roonlabs.com:443 -tls1_2ā€ and that one runs without issues. That said, running (on the same machine) with and without openssl doesnā€™t have any impact on the error messagesā€¦ so I donā€™t think itā€™s using openssl. In the Linux KB article, it doesnā€™t list any libraries such as openssl (which leads me to think that the list of dependencies isnā€™t complete - for 1.8 at least).

Unfortunately the manufacturer is defunct so Iā€™m on my own here and have to work with the OS thatā€™s there.

That is certainly something Iā€™m looking into. though the Roon Core seems to trigger an update even though Iā€™m telling it not to update. Iā€™m sure Iā€™ll find a solution for that.

4

I donā€™t think that RAATServer on your bridge wants to talk to roonlabs.com. I was in the believe that it manages RAAT connections between your Roon Server and the Bridge, but of course I know nothing for sure as Iā€™m not one of its programmers. :wink:

5

I donā€™t think so either. However, this is a decent test to know whether TLS 1.2 is supported (which seems to be the case). If that works, local encrypted connections should work as well.

6

As your example, documented in this thread, shows, this seems to be a false assumption.

Short brainstorming:

  • I donā€™t think I ever seen Roon mention which standard they use for encryption (heck, they even ā€œforgetā€ to mention that internal change at all in the release notes). Maybe theyā€™ve chosen a different standard.
  • IIRC are various encryption algorithms defined in the TLS standard, some of them optional. As in this case Roon controls both sides of the connection, they may have settled on a specific algorithm to be used or chosen a bundle of accepted ones, none of them supported by your bridge or flawed [generating weak ciphers that get refused by the server].
  • I assume there is also a certificate involved. I never looked into those. If your bridge uses outdated/incompatible libraries, might it be possible that loading the certificate already fails? One of the weak points of Roon as I see it is that Roon software does a bad job when it comes to error checking and handling. The reason behind all the ā€œRoon just hangs on logo screen and never startsā€ and similar threads. What if reading the certificate from file fails and RAATServer doesnā€™t catch the error and just goes on? The server maybe rightfully refuses the connection because instead of the expected certificate he just gets an empty string or the uncaught error message.

Maybe you can find out more about why the connection got refused on the server (MacBook?) side of the connection as the client side exception code is not very specific.

7

Hey @TheRealMuffin,

Thanks for not hesitating to post on community when you ran into this issue - weā€™re sorry that for something as critical, we didnā€™t get the opportunity to reply right away :pleading_face:

Thankfully, the Roon community came to help - thank you @BlackJack for the helpful posts.

Since itā€™s been a while, @TheRealMuffin, I was wondering if things have improved at all? Is there anything left unresolved? Weā€™d love to help, albeit much later than we had hoped (so sorry about the delay!)

8

Apologies for the late reply. Spent quite a bit of time digging into it, was hopeful for a few momentsā€¦ ended up where I started, got demotivatedā€¦ well, itā€™s tricky debugging a black-box.

@BlackJack Thanks for your help, though no solution yet. In the logs for a Roon Bridge running on another system, I noticed it was connecting to https://bits.roonlabs.net/1/q/roon.base. The certificate for this one was missing (according to wget). Unfortunately, resolving that problem and adding the certificate did not solve the issue. I also noticed that Roon Bridge is using EasyHTTP for this http call, which might not use the system certificates (another challenge).

@beka Help was indeed quick and gave some good pointers. Unfortunately, the problem isnā€™t yet solved. Any help I could get in getting to the cause (and resolution) of this issue would be much appreciated.

9

Hey @TheRealMuffin,

I cannot do anything else but thank you for your dedication in seeing this through, even when you felt demotivated. Or, getting over the lack of motivation. Weā€™d love to lend a helping hand.

To get a better idea, could you please zip up your entire Logs folder and upload it here?

Please, let us know once you had a chance to make the upload (weā€™re not being notified). Thx :pray:

10

Hello @beka,

Sounds good! Iā€™ve uploaded the RoonBridge/RAATServer/terminal output to the given location (name ā€œRoonBridge @ Linux ARMv7hfā€).

Couple of comments:

  • The most explicit error is in the terminal output (displayed when running start.sh).
  • RoonBridge seems to load fine (it also appears in the About section of Roon Server - but not the Audio section - which is basically the problem).
  • RAATServer never gets beyond detecting ALSA Support, but sometimes not even that far.
  • RoonBridge 1.7 runs without issues, even when running RoonServer 1.8.
11

Hey @TheRealMuffin,

Sorry we only got back to you today, after the weekend :nerd_face:

Weā€™ve received the logs and they have been sent to our technical team for investigation. Iā€™ll follow up as soon as I hear back :pray:

Thanks in advance for your patience!

15

Anything update? I met the same problem on Debian 11 armhf (also failed in 9 and 10).

16

@user21 Thanks for sharing that info! To be sure, can you confirm the error message is identical to what I shared in the initial post?

@beka Can you update us on the status of the investigation into this issue?

17

Hi @TheRealMuffin ,

Thanks for your patience here while we checked with the team on this one. This looks like it could be a TLS issue, as weā€™ve upgraded TLS version recently.

We have not tested older kernels against the new TLS, and the kernel version may be playing a part here.

Weā€™re going to check with the dev team to see if anything can be done here, but for the time being, can you please use another RoonBridge?

Thanks!

18

We have not tested older kernels against the new TLS, and the kernel version may be playing a part here.

I am compiling kernel for my device; may I know which option(s) will work on this issue? I have enabled TLS related options but nothing changed. Thanks.

19

Yes, exactly same, even the error code.

20

Hi @noris,

Just wanted to let you know that there are more users, including myself, having these issues currently on older kernel versions with RoonBridge.

but for the time being, can you please use another RoonBridge?

Unfortunately this isnā€™t possible since the RoonBridge device is a streamer and amplifier. There are workarounds possible for now, but it would be nice to be able to use the RoonBridge functionality once again. Hopefully the investigation on TLS with older kernel versions will lead to a solution sometime soon.

22

Hey @Felix_Hendriks,

Thanks for updating us on this issue ā€” weā€™re definitely sorry itā€™s persistent and it is impacting your music listening experience to this extent.

Our technical team is on it :nerd_face:

Weā€™ll follow up shortly.

23

Hello @user21 ,

We have devices using Kernel 4.X and this should be working, but we suggest using Kernel 5.X and above if possible.

@Felix_Hendriks - We are still looking into the TLS on your older kernel version and we will let you know once we have more details on this, thank you.

24

What I tried is 5.10, I am sure there are some options affecting on it.