-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
“Could not connect to radio browser server” #1206
Comments
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: To install go to |
That's it! I installed the Which leads me to a couple of feature requests:
|
Can confirm Problem and solution. |
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. |
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/ |
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 |
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. |
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 |
Moin, ich hatte das gleiche Problem mit 2 Android 4.4.4 Radios. Auf der Seite https://letsencrypt.org/de/certificates/ unter: Aktiv Die "pem" und die "txt" Datei herunterladen. URL-PEM : https://letsencrypt.org/certs/lets-encrypt-r3.pem In dem Downloadverzeichnis den Hash der PEM-Datei ermitteln mit:
hier: dec71a0b Jetzt den Inhalt der .txt-Datei an die .pem-Datei anhängen mit:
Danach die Datei umbenennen in den Hashwert und ".0" anhängen mit:
Nun noch den SHA1 wert der Datei an die Datei anhängen mit: Das Zertifikat dec71a0b.0 per SD-Karte oder wie auch immer auf das Gerät übertragen. Auf dem Gerät muss ein Terminalprogramm installiert sein und der root-zugriff ermöglicht. Als erstes müssen root-Rechte erlangt werden mit: Jetzt muss die Systempartition mit lese- und schreibrechten gemountet werden mit: Danach die Zertifikatsdatei in den richtigen Ordner kopieren oder verschieben mit: Noch die Rechte anpassen mit: und das wars.... Wenn man jetzt unter den Einstellungen=>Sicherheit=>Vertrauenswürdige Anmeldedaten=>System nachschaut, |
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?). |
Kein Ding. Ich habe das im Großen und Ganzen auch nur aus verschiedenen Quellen zusammen getragen. |
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. |
Ich denke ich habe das benötigte Zertifikat heraus gefunden. |
Wow, vielen lieben Dank. 😊 |
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. |
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.
Ausgabe : c90bc37d
Auf den Androiden kopieren, verschieben, Rechte anpassen, neustarten, zack läuft ;-) |
@dilworks Greetings Translated with DeepL.com (free version) |
Vielen lieben Dank Tomm, auch von meiner Frau. Läuft wieder alles problemlos. 👌 |
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. |
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 I keep getting
[Edit] [Edit 2]
gives =>
and then presuming you have adb running and the target droid connected; otherwise copy via sd card or whatever to the droid For the second identically:
gives =>
Then connect to the Android via
Then move the files to their place and set the permissions:
File there, permissions correct? Then for the 2nd:
Again, file there, perms correct?
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. |
@Radoom |
@Radoom Thanks for fixing my crappy old radio again. 👌🙂 |
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... |
I added those two certs to /system/etc/security/cacerts on an Android 6 device, and now the stations connect and play. Thank you. |
@Radoom |
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. |
@alooshu reading your last paragraph, some (mess of) thoughts:
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. |
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.
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. |
|
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.
|
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?
The text was updated successfully, but these errors were encountered: