Verbindungsproblem mit TechniSat Techniradio 6IR

[bonax74]

[!TIP] Please also see Troubleshooting.

Radio-API Installation

• Version of Radio-API: 2.9.2
• Installation mode: Docker on OpenWrt router (Banana PI R3)
• DNS redirect via: AdGuardHome (DNS Umschreibung außer für time.wifiradiofrontier.com)
• Radio vendor: TechniSat Techniradio 6IR
• Usage of reverse proxy: yes (nginx)
• Does another radio use your installation of Radio-API: no

Describe the Issue

• Netzwerkfehler in der Verbindung des Radiogeräts zum Internet.
• Der GUI-Server funktioniert mit https hinter dem nginx reverse proxy (nicht dem im Docker!)
• CONF_DOMAIN != CONF_RADIO_DOMAIN = http://airable.wifiradiofrontier.com
• Die Seite CONF_RADIO_DOMAIN wird vom Radio aufgerufen, allerdings reagiert die Radio-API nicht
• Laut Wireshark, scheint das Radio die Port 443 (https) im Normalfall (also ohne DNS-Umschreibung) zu verwenden und nicht die 80.
• Das Docker-Image von Radio-API wurde mit docker compose im Router selbst erzeugt.
• Ports im Docker-compose.yml: 8070/80. Der externe nginx reverse proxy wandelt 443/80 in 8070 um, und zwar nach dem Code von dieser Seite.
• Keine Verwendung von Redis, Error Message or Log Files
  Keine Fehler seitens der Radio-API -> ./data/ auf dem Volume bleibt leer. Die Umleitung seitens von AdGuardHome findet statt und die Adresse airable.wifiradiofrontier.com wird in die lokale Adresse 10.0.2.1 umgeschrieben. Die Abfrage geht aber dann nicht weiter.

[kimbtech]

Hallo,

es erscheint mir komisch, dass das Radio versucht über HTTPs mit der API zu reden. Meines Wissens nach können die Frontier Silicon chips gar keine HTTPs Verbindungen herstellen.

Könnte es ein, dass irgendwie eine Umleitung stattfindet? Was ergeben die folgenden Curl-Befehle (von einem PC im gleichen Netzwerk ausgeführt):

• curl "http://10.0.2.1/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: airable.wifiradiofrontier.com" Es sollte <EncryptedToken>3a3f5ac48a1dab4e</EncryptedToken> herauskommen.
• curl "http://10.0.2.1/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: airable.wifiradiofrontier.com" -I Zeigt noch die von Radio-API gesendeten Header.

Grundsätzlich sehe ich spontan kein Problem darin, Radio-API auch über HTTPS zu nutzen [wenn ein Radio das kann]. Es müsste wahrscheinlich bei CONF_RADIO_DOMAIN ein https:// vorne stehen. Der äußere Reverse Proxy übernimmt ja schon die Annahme auf 443 und leitet intern auf 80 weiter. Jedoch wird es wohl schwierig passende SSL-Zertifikate zu bekommen. An welche für wifiradiofrontier.com kommen wir ja nicht dran. Man müsste wahrscheinlich im Radio irgendwie die Überprüfung deaktivieren oder ein eigenes Wurzelzertifikat hinterlegen (können).

Wenn das Radio mittels HTTPs arbeitet, dann sollten die folgenden Befehle analog zu den obigen funktionieren (-k deaktiviert die Prüfung der SSL-Zertifikate):

• curl -k "https://10.0.2.1/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: airable.wifiradiofrontier.com"
• curl -k "https://10.0.2.1/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: airable.wifiradiofrontier.com" -I

[bonax74]

Guten Morgen kimbtech,

und Danke für die Antwort. Also, zu den Befehelen oben:

1) curl "http://10.0.2.1/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: airable.wifiradiofrontier.com"

3a3f5ac48a1dab4e (wie Du sagst) 2) curl "http://10.0.2.1/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: airable.wifiradiofrontier.com" -I HTTP/1.1 200 OK Server: nginx/1.25.0 Date: Thu, 19 Sep 2024 07:56:04 GMT Content-Type: text/plain;charset=UTF-8 Content-Length: 49 Connection: keep-alive X-Powered-By: PHP/8.3.11 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache 3) curl -k "https://10.0.2.1/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: airable.wifiradiofrontier.com" Dasselbe Ergebnis wie im Punkt 1) 4) curl -k "https://10.0.2.1/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0" -H "Host: airable.wifiradiofrontier.com" -I Dasselbe Ergebnis wie im Punkt 2) Also es sollte funktionieren. Ich glaube eher dann an ein zertifikatbedingtes Problem. Wie im unteren Bild aus Wireshark, erfolgt die Kommunikation zwischen Radio (10,0.2.246) und dem "echten" airable.wifiradiofrontier,com (in dem Moment 217.33.180.98) auf 443 statt 80 mit Zertifikatsüberprüfung:  Das ist hingegen mit dem aktivierten Radio_API passiert. Die Abfrage erfolgt natürlich weiter nach "airable.wifiradiofrontier.com":  Hier sieht man dass der Router (10.0.2.1=airable.wifiradiofrontier.com in diesem Fall aus der DNS-Antwort) nicht auf die Anfrage reagiert. Auf dem Radio erscheint "Netzwerkfehler". In diesem Bild hatte ich die Verbindungstaste am Radio 3 mal betätigt, deshalb wiederholt sich die Reihenfolge bei der Abfrage. Wie Du sagst, ich kann leider kein passendes Zertifikat für "wifiradiofrontier.com" erzeugen.

[kimbtech]

Hallo, ja, das schein wirklich so zu sein, dass das Radio nun HTTPs kann und das auch gleich machen will. Das macht es für uns nun schwierig, da wir die Zertifikate überwinden müssen. Ich habe leider keine Idee, wie man das System austricksen kann 😢 – an sich ist ja HTTPs auch gerade dazu konzipiert, nicht ausgetrickst zu werden.

Ich sehe eigentlich nur die Möglichkeit, dass man irgendwo im Menü des Radios entweder die Prüfung von Zertifikaten ausschalten kann oder selbst Zertifikate hinterlegen kann.

Ganz allgemein zu dem Thema, dass Radios jetzt "HTTPs" können:

Gab es evtl. vor kurzem ein Update, sodass das Radio mit HTTPs nachgerüstet wurde oder ist das Radio neu? (Ich würde sonst einen Hinweis auf der Seite hier hinzufügen, dass man aufpassen muss, wenn man Radio-API weiterhin nutzen will.)

Bei meinem kurzen Blick auf airable.wifiradiofrontier.com scheint sich der Service auch anders zu verhalten, als die mir bekannten Services, die Radio-API nachbaut. Es scheint u.a. auch davon abzuhängen, ob ich mittels http oder https zugreife – alles komisch...

[bonax74]

Hallo,

die Einstellungsmöglichkeiten des Radios sind gering. Man kann darin einen speziellen DNS einstellen, das hilft aber selbstredend nicht. Es wird nirgendwo etwas über das verwendete Protokoll erwähnt, geschweige denn über Zertifikate. Das Radio ist nagelneu und hat von sich aus keine Option sich auf Frontier Nuvola anzumelden. In dem "Senderliste"-Menü gibt es ja keine Angabe über den notwendigen Anmeldungscode.... da würde es nur eine neue Firmware helfen. Schade, weil das Modell klein und fein ist. Ich werde es zurückgeben und besser auf diese Eigenschaften beim nächsten Kauf achten. Vom selben Hersteller gibt es (nach kurzer Recherche) einige Radios, die eine Anmeldung auf Frontier Nuvola ermöglichen. Sie sind aber um einiges teuerer als das Techniradio 6IR.

Vielleicht sollten Sie tatsächlich hier einen Hinweis darauf schreiben.

Jedenfalls Danke für die Unterstützung!

[tackin]

Hallo, ja, das schein wirklich so zu sein, dass das Radio nun HTTPs kann und das auch gleich machen will. Das macht es für uns nun schwierig, da wir die Zertifikate überwinden müssen. Ich habe leider keine Idee, wie man das System austricksen kann 😢 – an sich ist ja HTTPs auch gerade dazu konzipiert, nicht ausgetrickst zu werden.

Ich sehe eigentlich nur die Möglichkeit, dass man irgendwo im Menü des Radios entweder die Prüfung von Zertifikaten ausschalten kann oder selbst Zertifikate hinterlegen kann.

Wenn der HTTPS-Stack im Radio korrekt implementiert ist, gibt es keine Möglichkeit per "Man-in-the-middle" das Gerät "auszutricksen" oder ein Zertifikat unterzuschieben. Wenn das möglich wäre, dann wäre auch Internetbanking und alles andere sofort "tot". Denn in dem Fall bräuchte man nur den DNS irgendwo auf der Anfragestrecke zu "verbiegen" und sich dann mit dem "Trick" erfolgreich gegenüber jedem Browser als jede beliebige Webadresse ausgeben und das per HTTPS.

Ein Ansatz wäre evtl., dem Radio welches mit https anfragt, ein unzertifiziertes "redirect" zu senden (301, 302 oder 307) und zu hoffen, dass es das auch unauthorisiert "frisst" (normalerweise bekommt man im Browser da ja eine Warnung).

[tackin]

einige Radios, die eine Anmeldung auf Frontier Nuvola ermöglichen

Hmmm ... ob das noch Zukunft hat? Frontier-Nuvola übergibt seinen Dienst im November an airable: https://www.airablenow.com/fs-nuvola-shutdown/

[kimbtech]

Hallo,

zuerst zum TechniSat Techniradio 6IR von @bonax74 : Ich nehme dann an, das nutzt dann eine ganz andere API und wäre wohl auch nicht mit Radio-API kompatibel.

Genau @tackin, wenn HTTPs korrekt implementiert ist, dann sind wir machtlos das Radio auszutricksen (solange es keine Einstellungen dazu gibt). Ich denke, auch ein Redirect mittels HTTP auf dem HTTPs Port zu senden wird eher nicht klappen, denn das Radio sollte ja als erstes mit dem SSL Handshake anfangen und bei einer unverschlüsselten HTTP-Antwort sofort abbrechen. Quasi wie bei ein Aufruf von https://github.com:80/ (SSL auf dem HTTP-Port).

Das Thema mit https://www.airablenow.com/fs-nuvola-shutdown/ müssen wir genauer beobachten. Ich frage mich da ja vor Allem, ob die Hersteller dann ein Update rausbringen, welches dann das Radio auf die neue API von Airable (um-)codiert oder wie es sonst gehen soll. Fazit: Erstmal, wenn man Radio-API sicher weiter nutzen will, keine Updates machen.

[bonax74]

Hmmm ... ob das noch Zukunft hat? Frontier-Nuvola übergibt seinen Dienst im November an airable: https://>www.airablenow.com/fs-nuvola-shutdown/

Ja, obwohl einige Hersteller schon den Umzug auf Airable schon angekündigt haben. Technisat ist unter Ihnen. Aber wie gesagt, das Problem auf meinem Radio kann nicht durch Radio_API gelöst werden. Airable ist aber nicht der einzige Dienstleister. Es gibt auch SkyTune und Mymediayou, die von anderen Radios benutzt werden.

Das beste Modell (Preis/Leistung) ist eines von Renkforce. Leider ohne Farbdisplay, es hat aber einen internen WebServer wo die extra Stream-Adressen per Computer eingegeben werden können. Für die Übrigen Streams verwendet es SkyTune.

[bonax74]

Hallo,

zuerst zum TechniSat Techniradio 6IR von @bonax74 : Ich nehme dann an, das nutzt dann eine ganz andere API und wäre wohl > auch nicht mit Radio-API kompatibel.

Genau, mein Radio verhält sich eben anders. Ich habe ein 8 Jahre altes Radio von Numan in einer anderen Wohnung und dies ist bei Nuvola Frontier seit langem angemeldet. Ich werde auch mit diesem Radio die Radio_API ausprobieren. Da dürfte es aber funktionieren. Der Hintergrund ist: Einige von mir gehörten Radiosender haben nach und nach von mp3 auf hls/aac umgeschaltet, womit das alte Radio nichts anfangen kann. Durch eine Umkodierung der Streams und Icecast2-Server auf meinem Router konnte ich aber das Problem lösen. Dafür muss man aber eben die Playlist im Radio selbst einstellen können.

Fazit: Erstmal, wenn man Radio-API sicher weiter nutzen will, keine Updates machen.

Und sich die Bedienungsanleitung vor dem Kauf genau anschauen :-)

[tackin]

Ich frage mich da ja vor Allem, ob die Hersteller dann ein Update rausbringen, welches dann das Radio auf die neue API von Airable (um-)codiert oder wie es sonst gehen soll.

Einfachste Lösung wäre: airable übernimmt die alte Domain und bietet dort die alte Frontend-Funktionalität weiter mit http. Daten kommen aber aus der airable-db.

[kimbtech]

@tackin Ja, die Domain und API zu übernehmen wäre nach mit den vorhandenen Geräten am einfachsten, mal sehen.

@bonax74 Ich schließe das Issue jetzt, sollte sich bei dem Radio von Numan noch ein Problem ergeben, dann bitte ein neues Issue dazu öffnen.