Redirect issues with RX-A1040

[jpouyaud-perso]

Hi

I would like to contribute with the test I did with my RX-A1040

unfortunately, this is not working.

here is the setup

DNS radioyamaha.vtuner.com => nginx server (runing on a NAS synology)

DNS conf:

server {
    listen 80;
    server_name *.vtuner.com
                192.168.2.110:80
                ""
                ;

    access_log /var/log/nginx/ycast_access.log;
    error_log /var/log/nginx/ycast_error.log;

    location / {
        proxy_redirect  off;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_pass http://localhost:8181;
    }
}

The reason why I've put my RFC1918 IP add 192.168.2.110 is because I've discovered my RX-A1040 set the Host field with the IP address and not the FQDN...

I'm using the release package 0.9.8 of ycast with python3

I've finally managed to get "access error" (previously I've obtained "please wait" and nothing shown in the Ycast consol)

Here are 2 pcap: one is the trace of the RX-A1040 taking with the official server on internet the second one is the trace with ycast

cheers

cap_yam_ycast_prod_0_9_8.pcap.zip packet_trace_LAN_INTERNE.pcap.zip

[milaq]

Hi,

it seems to me that the issues you are experiencing are related to https://github.com/milaq/YCast/issues/19.

The version you are using uses redirect by default. We disabled that later due to many users having issues with it (https://github.com/milaq/YCast/commit/1b4ba071b7f27cf853ca572a5ed1dbb9d090494d).

Nevertheless, redirects should work if you leave the host header intact. For redirects to work properly, your AVR expects the host field to start with http://radioyamaha.vtuner.com. This seems like a security measure by the vendor.

Looking at your packet capture (thanks for that) it seems indeed like your A1040 is using http://192.168.2.110:80 as request URI host. In the second pcap I can see that your AVR is indeed using http://radioyamaha.vtuner.com in the host field.

I know at least one other user which had a problem with his Synology NAS handling HTTP requests. Is the the Nginx service directly accessible or are you (or Synology) doing any kind of redirecting and/or filtering before it?

[jpouyaud-perso]

Hi Milaq well, not sure to understand well your question

the Nginx service is the native of of synology

I've just added my server/nginx in the sites-enabled config folder

if I understand well I've to check the behavior of my Nginx

[jpouyaud-perso]

Hi again,

looks like you are wrong with my initial pcap file

in both of the we see AVR to set host field with an IP add

the first file is when I use ycast the second file is when the AVR goes to Internet

I've just tried https://github.com/milaq/YCast/commit/1b4ba071b7f27cf853ca572a5ed1dbb9d090494d without success => I've also 302 but another error :

2019-09-10 14:02:46 ERROR: Unhandled upstream query (/setupapp/yamaha/asp/func/dynamOD.asp)

cheers

[jpouyaud-perso]

hi

here is another trace with the official 0.9.8

cheers cap_yam_new.pcap.zip

still not working, but different, I've long wait on the AVR screen with some "access error" showing no content

[milaq]

Hi there,

the request from your AVR to the original vtuner API (radioyamaha.vtuner.com) has the host header set to radioyamaha.vtuner.com. See https://i.ibb.co/FgvpV0k/screenshot-2019-09-10-23-20-39.png

Your second capture with YCast active (and the newest one from above) has 192.168.2.110 in the host header. See https://i.ibb.co/smGyZM1/screenshot-2019-09-10-23-31-33.png This will not work due to the whitelisting I explained above and in the referenced issue. Your AVR does not accept redirects from URLs other than *.vtuner.com and just discards the answer.

You need to have radioyamaha.vtuner.com in the host header. That's why I asked whether you do any kind of filtering or redirecting before Nginx. Something seems to manipulate the host header, i.e. resolve it to the IP of your Synology.

Please just use server_name *.vtuner.com; and make sure there is nothing in between Nginx and the AVR.

[milaq]

Another user recommended that you can also test this by using an Iptables redirect to make sure that every packet from your AVR gets passed to YCast: iptables -t nat -A PREROUTING -s 192.168.2.122 -p tcp --dport 80 -j REDIRECT --to-port 8081 (where 192.168.2.122 is the IP of your AVR).

You could also stop any webserver on the machine and run YCast as root without any arguments to have it listen on port 80. Make sure to revert this change once you're done with testing. It is still not recommended to run YCast as root.

Also, where do you handle the DNS redirects? On what machine/device?

[jpouyaud-perso]

Hi Milaq,

please look at the whole pcap trace. you will see that the AVR start with the Host field as an IP and finish with the FQDN. I don't know why my AVR behave this way, but this is what he does is both situation (toward internet and toward my nginx/ycast)

the last trace is not representative as it's only the early beginning of the conversation

anyway, I will try the iptable PBR

cheers

[milaq]

It seems like your AVR first resolves radioyamaha.vtuner.com correctly to 192.168.2.122 192.168.2.110 and then, after an SSDP (for upnp) it caches the IP of your Synology's IP and accesses everything there with the IP instead of the hostname.

YCast formats the redirect URLs by the host header. This is why the (newer) redirects don't work correctly. It sees the host header 192.168.2.122 192.168.2.110 and redirects also to that IP which your AVR does not accept because of the internal whitelist.

We either need to find out why and how this happens or hardcode the redirect URLs based on the accessed path, i.e. /setupapp/yamaha/[...] redirects to radioyamaha.vtuner.com.

In the meantime, you can also use the lastest dev branch which doesn't use station tracking (thus no redirects) at the moment.

[jpouyaud-perso]

Yes, agree with you. just a small correction (192.168.2.122 is AVR and 192.168.2.110 is the Synology/Nginx/ycast)

I will try the last dev tonight. I've already tried without success 2 days ago. I will put a trace

cheers

[jpouyaud-perso]

Ok, just tested the last /dev and I've some redirect 302 and also a 404

here is the trace cap_yam_new.pcap.zip

[mnasec]

Hi Jasonbarebone, i looked at the trace and could not find any real data from the ycast software, only from the reverse proxy. I am using ycast on my synology in a docker container and had problems with the nginx to forward the get requests correctly. Please be so kind and describe your setup a little bit. Personally i ended up in running ycast in a docker container and forwarded the requests with the iptable nat rule Milaq reported. This works on my platform very well and stable. CU

[jpouyaud-perso]

hi guys,

both of you are fully right ! I've just installed directly the ycast/dev on the mac and I'm able to listen 1970 radios !! I've some 404 but it's definitely working better

PS: the 0.9.8 was not working for me

thanks for the hint. looks like nginx was wrongly configured in my setup

I'm waiting for a Raspberry, this way it will more stable in the time

cheers

[mppod]

Gents,

I have rx-a2010 and can confirm that this AVR also puts IP in the GET header's Host field. Consequently, the easiest way to use Nginx is to filter with /setupapp and /ycast - this works for me (the given example config does not work).

The script works great - vtuner did us great service switching itself off. ;)

[milaq]

Thanks for your input @mppod. I am currently working on working around the issue you are describing by filtering the access urls by vendor. That way it doesn't matter what the AVR puts into the headers.

You can track this in https://github.com/milaq/YCast/issues/19