Yes I know, but it thought you used a dedicated roon bridge as well.
Only running Roon Bridge (standalone) on a Windows machine here.
Note: It might as well be an issue with your distribution (libraries/software supplied) rather than the kernel.
Another BBB users with issues reported once he resolved it by switching to another distribution.
Debian has sometimes a very unique look at things, therefore omitting support for stuff users of other distributions can take for granted.
Yes, I read a lot of BBB messages, but none of them seem to have resolved the issue, or they did not state so. I have also tried a very basic busybox, did not work either. Although modules where thus not loaded in. I will try Alpine. It is weird it used to work, even now I can run an older version of Roon Bridge pre 1.8, but not 1.8. They for sure did change something, the changelog should mention major differences. However it seems like it does not.
Also: Roon says debian should be compatible.
They added encryption for all network connections (and forgot to mention it in the release notes).
Yes, that is what I discovered as well. I enabled TLS in kernel, but that does not seem to do the trick. So, what encryption is used.
Roon Labs never shared that information. Also not everyone who ran into this issue is using a BBB. I link to oldest related thread I know of for reference:
That is the same board as I am using. I have reversed engineerd a new kernel for that board (5.10). That board is a custom am335x, which is basically based on the BBB. I thought there might be more appael if I would say BBB as I can run any BBB kernel and visa versa. Might be a am335x problem. I am now able to configure the kernel, Maarten was not, we thought this could resolve the issue. I still think so, because I think it is very unlikely it is a hardware issue. The problem is it is hard to know the exact issue (probably encryption, but what). We just get a connection refused, not a message which states why exectly the connection is refused which you usually get in .NET.
See my third point in the linked post. As Roon Labs so far never came back with results from analyzing the log files they got, … no one is any wiser. A software change might be needed to get better error reporting but it seems Roon Labs never implemented that.
PS:
On a side note: Users of Ubuntu 18.04 could no longer use Roon (on Wine) for a very long time after that change too, while users using more modern Ubuntu or other distributions had no issue. This got corrected some time ago when Roon Labs updated some old legacy code in their software. It was never clear to me if those same (or similar) changes were also included in Roon Bridge. Looks like probably not – or the two issues aren’t based on the same reason and just a coincidence. In lack of Roon Labs support in resolving either of them so far, we might never know.
Yes, In the case of this board they said it was the kernel which was too old and the OS. I managed to fix everything up, and am now just testing software. All works fine (Squeezelite, Tidal connect, Spotify connect, Airplay endpoint) except Roon Bridge. Certificates is unlikely since I use Debian 11.
Aren’t the certificates already encrypted (or cryptographically signed)? If your system lacks the cryptographic algorithm needed, how would your system be able to verify and use the certificate?
What I could make up in short time:
Issue between system libraries and .NET.
Issue of missing ciphers.
You may want to try and investigate in that direction but honestly I think you need a lot of luck to stumble upon the missing piece. It could probably be much easier to search for a solution if Roon Labs’s software could provide a meaningful error message about the actual issue instead of a generic one from several levels above the failure.
Thank you for the pointers and brainstorming will look further into this. I did just receive a message that the Roon Bridge in HifiBerry OS does seem to work on BBB which is noteworthy. Might try this.
I have now used the RAAT SDK which is used for Roon Ready devices, just for test purposes, not to end up using. Which works like a charm. Seems clear this issue is in Roon Bridge. I am now even wondering how Roon Bridge is tested, or if it even gets tested.
As I wrote, I run it on Windows without issue and I’m pretty sure many users also run it on x86 Linux without issue. It is also known to work on RPis. That a user/tester also has a BBB (or other platform) specifically that produces an issue though is rather unlikely. Also that Roon Labs didn’t really took the time so far to look into this speaks for it self I guess.
Yes, however BBB is armv7. RPI is armv8. In my opinion they should come up with a solution, the roon ready RAATServer works, but Bridge not.
I am still convinced it can be solved within kernel. Otherwise, hope for the best with a 1.9 release.
I just looked into it a bit further the last message RAATServer returns according to the log:
11/17 17:54:26 Debug: [easyhttp] [1] POST to https://bits.roonlabs.net/1/q/roon.base.,roon.internet_discovery. returned after 6768 ms, status code: 200
When I enter this to get the JSON on the web:
{"roon.base.machine_id_blacklist":{"blacklist":[{"machine_id":"afa8b371-1d6e-e13e-69ff-16895e83526a","reason":"Touchbar:AC-DE-48-00-11-22"},{"machine_id":"4997afdc-9efa-92d5-bfdd-2426858873f2","reason":"Cisco VPN SSL:00-05-9A-3C-78-00"},{"machine_id":"c2845621 -28b2-68ed-39c4-cfc58ea1a939","reason":"Cisco VPN IPSEC:00-05-9A-3C-7A-00"},{"machine_id":"4d4b8709-f1e1-e7bc-2618-84369959e32c","reason":"Palo Alto Networks GlobalProtect Virtual Ethernet Adapter:02-50-41-00-00-01"},{"machine_id":"70c186ad-d200-ebb7-8fd8-2e4671593c1f","reason":"CMOS failure:88-88-88-88-87-88"},{"machine_id":"d50b0b88-1484-18b0-79a2-d735c9a1de44","reason":"Fortinet VPN:00-09-0F-FE-00-01"},{"machine_id":"9cdd21f0-17e5-f63e-1bbd-14a4 24ed13a9","reason":"Fortinet VPN SSL:00-09-0F-AA-00-01"},{"machine_id":"8f716840-e19f-aa74-a237-60031719a6e2","reason":"Checkpoint VPN:54-AE-D3-F5-86-0F"},{"machine_id":"e7f6b22b-c3b1-999c-7a97-53f143d33178","reason":"mu:54-B2 -03-12-19-CE"},{"machine_id":"a64758ff-51ec-6d1b-8361-e31c056d030e","reason":"12345:00-01-02-03-04-05"},{"machine_id":"c96b75bc-c2dc-57ee-91ac-23c61ce1206a","reason":"virtualbox"}]},"roon.internet_discovery.enabled":true}
Could it be that my Device is getting denied because it might think it has one of these circumstances? Would be helpful if support could respond.?
I have now managed to fix this issue. The issue is with mono/mono-sgen which is delivered in the RoonBridge package. You can fix it by doing the following: 1 Either build a mono/mono-sgen from source, or 2 install it with a package manager from whatever unix you are on.
Now:
In my case the mono-sgen is installed in /usr/bin/mono-sgen. You change the /usr/bin/mono-sgen with your location.
In /RoonBridge/Bridge/RAATServer you do the following:
cd "$ROOTPATH/Bridge"
if [ -x /bin/bash ]; then
exec /bin/bash -c "exec -a RAATServer /usr/bin/mono-sgen --debug --gc=sgen --server RAATServer.exe $@"
else
exec /usr/bin/mono-sgen --debug --gc=sgen --server RAATServer.exe "$@"
fi
Secondly please, please, please someone from Roon Support team tell this your Dev team, because it is a really easy fix which only takes 5 minutes.
It now works even better than before. On the 1.7 version of Roon it would first try to connect 4 times and give this error before being able to connect to the core. Now it does not give any error and connects immediatly.
2 Likes
Are you able to call in any support collaborator, and look at the above message? I have a fix.
Ok, thank you, I am not an advanced user of this forum and saw you were a moderator.
1 Like
For whoever needs it: GitHub - LarsGrootkarzijn/RoonBridge-BeagleBone. I am not certain if I am allowed to distribute like this. let me know if it is not allowed, then I will put it on private.