Medion MD88289 shows "Network Error" when being redirected to Radio API about radio-api HOT 9 CLOSED

Hi,

as you tested Radio-DNS with your computer this should not be the problem.
Do i assume correctly, that you set RADIO_IP to your Synology NAS' local IP and did not set RADIO_DOMAIN?

Now regarding Radio-API:
Did you check the troubleshooting section?
Especially trying the requests the radio runs with a browser?

• http://radioapi.local/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0
• http://radioapi.local/setupapp/iden/asp/BrowseXML/loginXML.asp?gofile=&mac=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&dlang=eng&fver=4&ven=iden00

Are there any requests in CONF_LOG_DIR/requests.log?
It only shows uncommon and unknown requests Radio-API got.
(Make sure to remove values for mac if you post the contents here, as the mac is the radio's token.)

If it works fine until here, does the following request run fine?
curl http://radioapi.local/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0 -H "Host: medion.wifiradiofrontier.com"
(This uses curl in a unix command. I would like to assure that the Synology NAS also answers correctly for the host medion.wifiradiofrontier.com. Thus, I send the request to radioapi.local and set the host header to medion.wifiradiofrontier.com. Using this command we do not need to use the Radio-DNS on a computer.
Otherwise, you could change your computer's DNS server temporarily to Radio-DNS and check, if http://medion.wifiradiofrontier.com/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0 works.)

When changing your radio to use Radio-DNS and Radio-API the access to Nuvola Service will not be available.

from radio-api.

Wow, thanks for the quick answer with so many good hints!

So starting from the top:
No, I used RADIO_DOMAIN (set to radioapi.local) instead of RADIO_IP because the Synology NAS runs several http services and won't allow making radioapi available on SynologyIP:80 .
Actually, I just started digging a bit deeper into how Synology manages these different http services. The mode I am using is called "virtual hostname" (which I set to "radioapi") and my understanding is that this virtual hostname is made available in the local network as "radioapi.local" by the Fritz!Box. The second option that Synology offers is called "Alias". It would create something like http://SynologyHostname/radioapi. But Radio-DNS does not seem to accept the / in the RADIO_DOMAIN. Option 3 for Synology would be a custom port (other than 80), but to me it seems like this also cannot be configured with Radio-DNS.

I tried the two requests from the troubleshooting section (from a browser on my PC) and the returns are as expected.

Regarding CONF_LOG_DIR/requests.log. Am I right that CONF_LOG_DIR should be the ./data/ directory that I mapped as a volume for docker? It only contains the three files env.json, podcasts_1.json and radios_1.json, thus no logfiles.

The curl - command (run from an Ubuntu Terminal) yields an Error 404 html page generated by the Synology NAS. After setting my PCs DNS server to the Radio-DNS IP, http://medion.wifiradiofrontier.com/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0 called from a browser returns the token.

from radio-api.

Hi,

I think it would be better to use RADIO_IP instead of RADIO_DOMAIN with Radio-DNS if the ip address and domain are locals ones. (Internally Radio-DNS does a global DNS lookup for RADIO_DOMAIN and if your domain is a local one, the DNS lookup will fail, as the domain is not globally known. At least it fails when I try it with a .local domain.) Using RADIO_IP is creates no problems with different services on the same ip beneath Radio-API. Radio-DNS is only used to give the ip where Radio-API is hosted to the radio.

Now a short and somehow simplified description how the radio does the HTTP requests:

1. Run DNS query for medion.wifiradiofrontier.com to configured DNS server (this should be Radio-DNS). The radio remembers the returned IP address, e.g., 192.168.0.12.
2. Run a check to Radio-API (the radio now thinks it would connect to Nuvola Service, but we tampered the DNS and returned 192.168.0.12 as ip to use).
   • Connect to 192.168.0.12 (only the IP address is taken from the DNS query)
   • Set the host name Host: medion.wifiradiofrontier.com (this is hard-coded in the radio's chip)
   • Query the path /setupapp/iden/asp/BrowseXML/loginXML.asp?token=0 (iden may be medion or hama ...)
   • Make sure the response is <EncryptedToken>3a3f5ac48a1dab4e</EncryptedToken>
3. Radio will show a success message and do a next request to fetch the list of items (Radio, Podcasts, ...). Again using 192.168.0.12 with the host name medion.wifiradiofrontier.com.

The radio is quite strict about the services it queries via HTTP and Radio-API must answer this requests. Thus, we can not change the port to something other than 80 or add a custom path prefix. We also need to make sure, that the Synology NAS knows that all request for the host name medion.wifiradiofrontier.com need to be passed to the Docker container running Radio-API.

It might be an idea to use the reverse proxy from Synology (https://kb.synology.com/en-us/DSM/help/DSM/AdminCenter/application_appportalias?version=6#b_80) with something like source (HTTP, Hostname medion.wifiradiofrontier.com, Port 80) and destination (HTTP, Hostname radioapi.local, Port 80) or even better directly the docker container as destination. For the destination you could also freely choose a hostname and a port, it just needs to match (locally in the Synology) with the hostname and port of the Docker container running Radio-API.

Ok, wheren there is no requests.log there are no unknown requests 😄.

I think, it is a problem, that curl http://radioapi.local/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0 -H "Host: medion.wifiradiofrontier.com" shown a Synology error message. As described above, the request curl http://192.168.0.12/setupapp/iden/asp/BrowseXML/loginXML.asp?token=0 -H "Host: medion.wifiradiofrontier.com" would be exactly what the radio does. Sending the request to the ip of Synology together with the host name medion.wifiradiofrontier.com. (On my server I also run many other services beneath Radio-API and for the curl request works there.)

from radio-api.

Possibly the radio queries for aldi.wifiradiofrontier.com instead of medion.wifiradiofrontier.com. Hence, you may better set the hostname *.wifiradiofrontier.com with the source of the reverse proxy (the * matches all).

from radio-api.

Thanks again for the outstanding support and the great suggestions. I am really learning a lot here! :)

Now, I think I got much closer to getting it to work, but there seems to be something missing. This is the setup now:

• Radio-API is made available on the Synology NAS based on a custom port with http://SynologyIP:customPort.
• A reverse proxy is set up on the Synology NAS with Source: HTTP, medion.wifiradiofrontier.com, Port: 80 and Target HTTP, SynologyIP, Port: customPort. (It won't allow wildcards here, but I saw from the Radio-DNS log that the radio does indeed query for medion.wifiradiofrontier.com.)
• RADIO_IP is used in the Radio-DNS config instead of RADIO_DOMAIN and set to SynologyIP

The result is that I am now no longer getting an error when opening the Sensorliste on the radio. It also shows the expected Items in the list including the radio's GUI code. Inside of ./data/table.json, an entry for the radio including its mac has been added and I am able to edit the lists from my computer's web browser. However, when I try to open any of the lists (for instance Radiosender), the radio reports a Network Timeout. The message appears immediately, so it does not feel like a real timeout to me.

Do you have any further suggestions?

from radio-api.

Hi, that sounds great.

I have to admit that I somehow saw the new issue already.
I think you still have http://radioapi.local as CONF_DOMAIN for Radio-API?

Radio-API will provide this domain to the radio for subsequent requests, i.e., Radiosender is a link to CONF_DOMAIN/cat?cid=1. However, the .local domain names are no real domain names based on DNS and thus I imagine, the radio is not able to open the link http://radioapi.local/cat?cid=1.

Now there are two possibilities:

1. Set CONF_DOMAIN to http://medion.wifiradiofrontier.com, this should (will) work, but you will fail opening the gui in a browser, because the computer with the browser does not query Radio-DNS.
2. Set CONF_DOMAIN to http://SynologyIP:CustomPort. The radio is able to open ip only http links and I hope, it is also able to open different ports than 80 if the url says so (I know this is true for audio streams). Thus, Radio-API will provide http://SynologyIP:CustomPort/cat?cid=1 as url of Radiosender to the radio. Using this possibility also the gui will be available on a computer at http://SynologyIP:CustomPort/gui/.

Summarized, I recommend to try 2. first and if it does not work 1. Hopefully 2. will work and then Radio-API should be fully functional.

from radio-api.

Yeah! It's running now. Thanks a lot! :)

However, I had to use Option 1 because Option 2 did not work (actually, Option 2 was exactly what I had configured already).

For me, it will be totally fine like that because I will most likely just set up the list of favorites once and then just keep listening to them on the radio... :)

from radio-api.

Happy to hear that it works now!

I will possibly add an option to define different domains for the GUI and the radio itself.

from radio-api.

Hi, I have also a Medion Radio here. I am running the docker radio-api and radio-dns on proxmox.

I have three Pixis Radio running well with that setup. I am using CONF_IP.

The Medion Radio got on Startup this "Network Error".

Any ideas?

from radio-api.