“Could not connect to radio browser server”

[atom-smasher]

On an Android-TV box, running Android-6… I tried clearing cache, clearing data, reinstalling via F-Droid, reinstalling via github release, reinstalling via Aurora, downgrading, and this is just not working.

Before I cleared data, I could “share” a station from RadioDroid to Kodi and it would play fine, in Kodi. Trying to play the station on RadioDroid, it would just spend hours trying to connect.

This seems to be related to #1199

That resolved itself, then got worse.

Now, all RadioDroid does is tell me that it “Could not connect to radio browser server”. It's as if this one app on this device can't access the internet.

I'm using RadioDroid on two other devices, same LAN, with no problems.

How can I troubleshoot on the Android-TV box, to see where the problem is?

[Baryczka]

EDIT:At first I put this comment in wrong ticket but I see it is the same issue 😅

I might fixed it on my device by installing Root certificate from https://letsencrypt.org/certificates:
First check if you have current Root certificate of LetsEncrypt in Android Settings>security>TrustedCredentials and search for Internet Security Research Group If it is not there then try to download them (pem files) from those links or above one

• https://letsencrypt.org/certs/isrgrootx1.pem
• https://letsencrypt.org/certs/lets-encrypt-r3.pem

To install go to Android Settings>security>Certificate storage:Install from SD card, and select those two .pem files. Then try to play any station.

[atom-smasher]

That's it! I installed the lets-encrypt-r3.pem cert, and it's working!

Which leads me to a couple of feature requests:

• There should be a clear error message if connection fails due to a bad certificate, or

• There should be a built-in certificate mechanism

• There should be a way to transfer settings and favourites between devices

[Radoom]

Can confirm Problem and solution.
Over here on Android 5.0.1, dated Samsung S4 used with a Samsung docking station for which drivers only ever existed in original Samsung firmwares :-( ... but it is used for radio droid only feeding into a much much much older hifi system - which !!thanks!! to RadioDroid has web radio :-)

[grave-digga]

The solution doesn't work for me. My settings didn't have the security tab, so i just installed the 2 certificates with a certificate installer. Still get the "Could not connect to radio browser server" message.

[atom-smasher]

On my Android-6 TV-box, a user-installed cert produces a persistent notification about "Network may be monitored", and a warning about the network being monitored by a third party.

This can be resolved easily - https://f-droid.org/en/packages/com.nutomic.zertman/

[dilworks]

This doesn't work for me on an Android 7.0 (Nougat) cellphone - an Alcatel OT-5044R.

I am able to install the required certs, but due to more security theater from Google[1], apps targeting API level 24 and later (that is, 7+) will gleefully ignore any user-added CAs unless the app itself opts-in (and this is not a default configuration for your average project!).

I know, I could just spend another $50+ I do not have to replace a perfectly working cellphone (that it's used for basic stuff, nothing particularly "sensitive"!), but I would prefer to find a fix to this as I'm not keen on generating e-waste. Rooting the phone is not an option (can't find trusted root procedures for this model, nobody really cares about "free-with-fries" prepaid phones in the modding scene).

[1]https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html

[jeronipaul]

Same problem in Android 6 with two different Phones. Installing the certificates fixes the problem but causes a warning "Network may be monitored".

I don't understand why Android 6 has this issue but not Android 4 or 7 where I also use Radiodroid without issues.

[apuser31]

On my Android-6 TV-box, a user-installed cert produces a persistent notification about "Network may be monitored", and a warning about the network being monitored by a third party.

This can be resolved easily - https://f-droid.org/en/packages/com.nutomic.zertman/

I tried adding 2 certs and now get the same "monitored" message. I tried the Move Certs app as mentioned above, but it won't work since phone (Android 4.4.2) is not rooted. Is there any other solution? Thanks

[Onkel-Tomm]

Moin,

ich hatte das gleiche Problem mit 2 Android 4.4.4 Radios.
Hier eine kleine Anleitung die bei mir funktioniert hat und es keinen Sperrbildschirm gibt.
Das Gerät muss allerdings gerootet sein

Auf der Seite https://letsencrypt.org/de/certificates/ unter:

Aktiv
° Let’s Encrypt R3 (RSA 2048, O = Let's Encrypt, CN = R3)
° Signiert durch ISRG Root X1: der, pem, txt

Die "pem" und die "txt" Datei herunterladen.

URL-PEM : https://letsencrypt.org/certs/lets-encrypt-r3.pem
URL-TXT : https://letsencrypt.org/certs/lets-encrypt-r3.txt

In dem Downloadverzeichnis den Hash der PEM-Datei ermitteln mit:

openssl x509 -inform PEM -subject_hash_old -in lets-encrypt-r3.pem | head -1

hier: dec71a0b

Jetzt den Inhalt der .txt-Datei an die .pem-Datei anhängen mit:

cat lets-encrypt-r3.txt >> lets-encrypt-r3.pem

Danach die Datei umbenennen in den Hashwert und ".0" anhängen mit:

mv lets-encrypt-r3.pem dec71a0b.0

Nun noch den SHA1 wert der Datei an die Datei anhängen mit:
openssl x509 -fingerprint -in dec71a0b.0 -noout >> dec71a0b.0

Das Zertifikat dec71a0b.0 per SD-Karte oder wie auch immer auf das Gerät übertragen.
Bei mir liegt die Datei dec71a0b.0 jetzt auf dem zu modifizierenden Gerät unter:
/storage/emulate/0/Download/dec71a0b.0

Auf dem Gerät muss ein Terminalprogramm installiert sein und der root-zugriff ermöglicht.
Als Terminal-Programm habe ich "Terminal" von ALIF Technology aus dem Plas-Store verwendet.
Es sollte aber auch jedes andere Terminalprogramm funktionieren.

Als erstes müssen root-Rechte erlangt werden mit:
su

Jetzt muss die Systempartition mit lese- und schreibrechten gemountet werden mit:
mount -o remount,rw /system

Danach die Zertifikatsdatei in den richtigen Ordner kopieren oder verschieben mit:
cp dec71a0b.0 /system/etc/security/cacerts/

Noch die Rechte anpassen mit:
chmod 644 /system/etc/security/cacerts/dec71a0b.0

und das wars....

Wenn man jetzt unter den Einstellungen=>Sicherheit=>Vertrauenswürdige Anmeldedaten=>System nachschaut,
ist in der Liste das Zertifikat von "Let's Encrypt R3" neu eingetragen.

[grave-digga]

Wow, danke für die tolle Anleitung. 👍 Hat auch funktioniert, die App läuft. 🤗 Was allerdings leider immer noch nicht geht sind Öffentlich Rechtliche Sender. Die werden zwar gefunden, man kann sie auch anklicken, angeblich werden sie abgespielt (also es gibt Play und Pause Funktion) aber man hört nichts. Alle privaten oder ausländischen Sender funktionieren problemlos. Bei Open Radio zeigt er mir bei den ÖR Sendern "network failed" an. Ich vermute ich brauche ein weiteres Zertifikat (SSL?).

[Onkel-Tomm]

Kein Ding. Ich habe das im Großen und Ganzen auch nur aus verschiedenen Quellen zusammen getragen.
Wir hören jeden Tag SR1 und das funktioniert. Welcher Sender funktioniert denn bei dir nicht?

[grave-digga]

Alles was ÖR ist, also SWR3/2/1/Dasding usw. Da kommt dann nur connecting, buffering. Dann das Play Icon, aber es werden keine Titel angezeigt oder sonstiges, natürlich auch kein Ton.

[Onkel-Tomm]

Ich denke ich habe das benötigte Zertifikat heraus gefunden.
DigiCert Inc. / DigiCert Global Root G2
Wenn alles klar geht, komme ich morgen dazu nach einem Zertifikat zu suchen und es für das Radio zu konvertieren.
Ich bleibe am Ball und melde mich wenn es klappt ;-)
Gruß
Tom

[grave-digga]

Wow, vielen lieben Dank. 😊

[dilworks]

I don't understand German, but... the instructions posted there seem to work only for rooted phones?

We need a solution for unrooted phones. Google proposes one (which is stupid, but it's the only one): change the project settings to trust user-added CAs0. For extra security, it can be even restricted per domain, although I don't see how viable would be to go in such a granular way. This is something that sadly has to be done at the project setup level.

See, I understand that user-added CAs can be abused as an attack vector, but the United Nations just reminded us that e-waste is growing at an alarmingly fast rate1, and in part it's due to planned obsolescence measures like this. At least Google gave us a way to workaround that, albeit it's strictly opt-in.

[Onkel-Tomm]

Jo, SWR3 läuft :-)

ich mache es jetzt mal in der Schnellausgabe. Im Prinzip alles wie oben, außer dass wir nur das .pem Zertifikat brauchen.
https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem

openssl x509 -inform PEM -subject_hash_old -in DigiCertGlobalRootG2.crt.pem | head -1

Ausgabe : c90bc37d

cat DigiCertGlobalRootG2.crt.pem > c90bc37d.0

openssl x509 -inform pem -in DigiCertGlobalRootG2.crt.pem -text -noout >> c90bc37d.0

openssl x509 -fingerprint -in DigiCertGlobalRootG2.crt.pem -noout >> c90bc37d.0

Auf den Androiden kopieren, verschieben, Rechte anpassen, neustarten, zack läuft ;-)

[Onkel-Tomm]

@dilworks
Sorry for what's coming. Since I can only read English and not very well at that, I have changed it to DeepL.
I'm not quite sure what you want, but you can also simply download the certificates on the Android. Then in the menu on "Security => Install from SD card" install the certificate and it will run.
The disadvantage is that a screen lock must be set up for this procedure.
I hope I was able to help you further.

Greetings
Tom

Translated with DeepL.com (free version)

[grave-digga]

Jo, SWR3 läuft :-)

ich mache es jetzt mal in der Schnellausgabe. Im Prinzip alles wie oben, außer dass wir nur das .pem Zertifikat brauchen. https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem

openssl x509 -inform PEM -subject_hash_old -in DigiCertGlobalRootG2.crt.pem | head -1

Ausgabe : c90bc37d

cat DigiCertGlobalRootG2.crt.pem > c90bc37d.0

openssl x509 -inform pem -in DigiCertGlobalRootG2.crt.pem -text -noout >> c90bc37d.0

openssl x509 -fingerprint -in DigiCertGlobalRootG2.crt.pem -noout >> c90bc37d.0

Auf den Androiden kopieren, verschieben, Rechte anpassen, neustarten, zack läuft ;-)

Vielen lieben Dank Tomm, auch von meiner Frau. Läuft wieder alles problemlos. 👌

[dilworks]

@dilworks Sorry for what's coming. Since I can only read English and not very well at that, I have changed it to DeepL. I'm not quite sure what you want, but you can also simply download the certificates on the Android. Then in the menu on "Security => Install from SD card" install the certificate and it will run. The disadvantage is that a screen lock must be set up for this procedure. I hope I was able to help you further.

Greetings Tom

Translated with DeepL.com (free version)

Already tried that, it won't work on my phone. The certificates will install fine, but ordinary applications will gleefully ignore them, as per Google policy. And yes, I have a lock pattern set.

The only way out is to change the app manifest to opt-in to user-installed certificates - this has to be done at the source level, compile the app, and it should work (according to Google instructions). Unfortunately I don't have an Android dev environment setup here so I can test this.

[Radoom]

tl;dr : for Android 5.0.1 (and likely 6, and maybe others as of today) see Edit2 below

Not sure what I'm missing, or what I'm doing wrong, or whether it is [Edit2: YES IT IS I'D SAY] because we are beyond June 6th, 2024 (when the "long cross-signed chain" support stopped entirely - see here, 2nd bullet point above the colorful image).

I did all your steps @Onkel-Tomm from your Mar-27 post and then also all those from your April 4 post.

Both resulting .0 files are in /system/etc/security/cacerts/ and are showing in Settings > More > Security > Trusted Credentials under System, also after a reboot.

I keep getting could not connect to radio browser server when I want to go to the stations list, and could not connect to station when trying to play a saved favorite.

Ideas? Need you guys to rescue me, WAF is closing in on minus infinity :-( She's literally threatening me with signing up for a sp*t!fy subscription... NOT a solution, darling.

[Edit]
Maybe we need another certificate or two "injected" on Lollipop aka Android 5.0.1 which I have and can't upgrade from?
See here: https://stackoverflow.com/a/78309587 - do we need those ISRG Root X1 and/or ISRG Root X2?
[/Edit]

[Edit 2]
YES that was it. One or both of those two needs adding. Steps:
For the first:

wget https://letsencrypt.org/certs/isrgrootx1.pem
openssl x509 -inform PEM -subject_hash_old -in isrgrootx1.pem | head -1

gives => 6187b673 which we need for the filename

cat isrgrootx1.pem > 6187b673.0
openssl x509 -inform pem -in isrgrootx1.pem -text -noout >> 6187b673.0
openssl x509 -fingerprint -in isrgrootx1.pem -noout >> 6187b673.0

and then presuming you have adb running and the target droid connected; otherwise copy via sd card or whatever to the droid
adb push 6187b673.0 /storage/emulated/legacy/Download

For the second identically:

wget https://letsencrypt.org/certs/isrg-root-x2.pem
openssl x509 -inform PEM -subject_hash_old -in isrg-root-x2.pem | head -1

gives => 8794b4e3

cat isrg-root-x2.pem > 8794b4e3.0
openssl x509 -inform pem -in isrg-root-x2.pem -text -noout >> 8794b4e3.0
openssl x509 -fingerprint -in isrg-root-x2.pem -noout >> 8794b4e3.0
adb push 8794b4e3.0 /storage/emulated/legacy/Download

Then connect to the Android via adb shell and run this to become root and remount /system as r/w:

su
mount -o remount,rw /system

Then move the files to their place and set the permissions:

cp /storage/emulated/legacy/Download/6187b673.0 /system/etc/security/cacerts/
chmod 644 /system/etc/security/cacerts/6187b673.0
ls -l /system/etc/security/cacerts/618*

File there, permissions correct? Then for the 2nd:

cp /storage/emulated/legacy/Download/8794b4e3.0 /system/etc/security/cacerts/
chmod 644 /system/etc/security/cacerts/8794b4e3.0
ls -l /system/etc/security/cacerts/879*

Again, file there, perms correct?
Then finally

mount -o remount,ro /system
reboot

And after the reboot, station list error is gone, and stations can be played. Happy wife, happy life :)

Hope we don't have to go through this pain every 30 days because the Let's Encrypt certs always expire after 30 days!? Pain in the A... but their strict policy.

[Onkel-Tomm]

@Radoom
Yes, that's it. It also worked for me with the 2 certificates.
Thanks for the tip :-)

[grave-digga]

@Radoom Thanks for fixing my crappy old radio again. 👌🙂

[Radoom]

Thinking about it... in theory, it might also work for non-rooted devices by simply importing the .pem files into the "User" certificate store - maybe? Shouldn't the system accept such "user" certificates same as those we force into the "system" certificate store as root? Why do they have to be forced in as root? I have no non-rooted device at hand to test this...

[atom-smasher]

I added those two certs to /system/etc/security/cacerts on an Android 6 device, and now the stations connect and play. Thank you.

[Onkel-Tomm]

@Radoom
You can also import the certificates in the user area, but then the device must be secured with a PIN or pattern and that is the disadvantage....

[alooshu]

I might try adding newer letsencrypt root cert as a user, but the (irrevertible except factory reset) obligation to define a pin, is real.I also opened https://github.com/segler-alex/radiobrowser-api-rust/issues/179 , I'm very happy it got addressed, but obviously, the exclusion of older device users is a recurring pattern and affecting enough people to have one issue opened after another.

Long story short: The API servers themselves are already perfectly happy with unencrypted HTTP requests, all that would need to change, would be a settings option to opt out of ssl/tls encryption, that change getting backported to the android 4.1 version of the app as the oldest still working legacy version AFAIK, and a release be made to f-droid.

Big thanks for both app and info server :), my current hack is manually querying the api with curl, fashioning little personal station name - station url documents from there and streaming from browser or VLC player, alas the app is better at reading Artist-Title metadata from the stream, keeping the tracklist, station history/favs, and recording, and I'm listening far less without it.

[Radoom]

@alooshu reading your last paragraph, some (mess of) thoughts:

1. IIRC recent browsers handle certificates themselves independent of the OS.
2. There are numerous radio stream player solutions out there, mostly some stuff embedded in the broadcast stations' Web pages to listen to their streams.
3. Is there a radio player add on for e.g. firefox? If we abandon "RadioDroid" and had something alike as a FF addon, and a FF version that still runs on the old devices.... Could the pair of the two be a better way forward?

But yes, to get rid of the https issue by using http would also do . . . what is the risk? A MITM attack where some bad folks swap out the nice(?) Whitney Huston stream for Metallica...or more likely in our odd times some propaganda sh*t. But other than that, what could happen? I'd be happy with that approach, too.

[atom-smasher]

3. Is there a radio player add on for e.g. firefox? If we abandon "RadioDroid" and had something alike as a FF addon, and a FF version that still runs on the old devices.... Could the pair of the two be a better way forward?

In the station lists, there's a down-arrow. Tapping that shows some options, including a "share" icon, which then allows the stream link to be copied and/or opened in a browser (or VLC). Inconvenient, but it'll work.

But yes, to get rid of the https issue by using http would also do . . . what is the risk? A MITM attack where some bad folks swap out the nice(?) Whitney Huston stream for Metallica...or more likely in our odd times some propaganda sh*t. But other than that, what could happen? I'd be happy with that approach, too.

1- As long as that's not the default option. I don't want Russian spies messing with my Whitney Houston 🤣

2- Bear in mind that a lot of servers are now configured to only accept HTTPS connections. HTTP is fast becoming a legacy protocol.

I suppose the best solution would be showing a meaningful/informative error message about invalid certificates, and inviting users to install certificates in the app itself.

[Radoom]

... and inviting users to install certificates in the app itself.
That would indeed be the best solution. Fix it all in the app, let it have its own cert store / management of expired certs.

[alooshu]

Let's keep in mind that the goal is a stable user experience that is resilient to obselencence, for users who refuse to throw away their working android devices. What you see happening on the issue tracker, confirms that they exist. That alone IMO rules out Firefox dependency as one more liability, so the other reasons speaking against it, do not need space. (the radio-browser.info website doesn't even load on FF 68 anymore, and that's where support got cut off for anything < android 5.0. Also, FF for android *only just recently* got back extension support, underlining the hell you'd be in depending on that. Can't deny there is a systemic 'bigger picture' somewhere if just innocently following development on all fronts, results in users getting cut off from radio-browser.info on both app and website simultaneously, but for different technical [un-]reasons. ) Whether a hypothetical change to RadioDroid, is the incorporation of its own cert handling (since both app and api server are controlled by the same project, that would theoretically also allow independence from LetsEncrypt via self signed certs of long validity), or the possibility to opt out of the https default - for being helpful, the important part would be to *backport* the change to a suitable existing legacy version, and make a release that people can install. Adding a https opt out checkbox would look like the less work intensive option. On that note, let's not mix the connection RadioDroid is making to the radio-browser.info database (where the breakage happens), with the actual radio streams. Most of the latter are unencrypted anyway, for $reasons, which highlights how cosmetic the repeated-breakage-causing security gain of encrypted db queries is in the whole picture. The real, not pretend, proven, already exploited vulnerability is in a totally different place: The social, distributed, anonymous nature of creating the database. At least until before this latest change locked me out, I was regularly running into imitations of Russian stations, used by 'activists' to place "F*** Putin" banners and similar; copying the original station icon instead and submitting a hijacking stream URL, (even a https one,) wouldn't be any harder. So why would an attacker bother to set up a MITM if they can have more impact at the central spot with less risk and effort, and why should legitimate users always end up paying the _real_ price for _imaginary_ (or superficially evaluated) problems. Once more, BIG thanks for keeping developing, and thanks for putting up with an issue tracker - if all this is coming up here and not the thousand places where it could arguably also fit, then this is not because you were doing a poor job - this project is great :) -, but because this particular small ecosystem is such an exemplary case, and still simple/modular enough for solutions to really happen.

…

-- Sent from my Android device with K-9 Mail.