Yamaha R-N500 Network Receiver Packet Capture

Last but not least I was interested which “home-calling” connections my Yamaha R-N500 Network Receiver initiates. In my previous post I already analyzed the open ports within the network, while I showed a complete Apple AirPlay capture here. This time I was only interested in outgoing TCP/UDP connections to the Internet as well as how the Yamaha App “NP Controller” communicates with the receiver.

It turned out that it was not easy for me to fully analyze such a packet trace even though only a couple of connections were made. It consists of many protocols that I am not familiar with such as UPnP, MDNS, SSDP, and RTP. Anyway, ere we go:


Again I captured with my ProfiShark 1G network TAP directly at the receiver. During the capture I:

  • powered the receiver on,
  • streamed something via AirPlay (not explained in this post but here),
  • walked through my netradio bookmarks,
  • started a network radio stream, and
  • changed the loudness and input source through the NP Controller App from my iPhone.

Furthermore there are many connections between the receiver and my local router which were initiated by themselves.


Initiated Connections to the Internet

In the following section I am separating the connections into these situations:

  1. after I powered the receiver on, hence real “home-calling” connections,
  2. after I started the Internet radio streaming, and
  3. single NTP requests.

The receiver did the following DNS queries to my local DNS resolver:

  • radioyamaha.vtuner.com (CNAME primary13.vtuner.com to and  radioyamaha2.vtuner.com (CNAME backup2.vtuner.com to vTuner is an Internet Radio platform which is used by many radios.
  • c14000-l.i.core.cdn.streamfarm.net and item.radio456.com.

There are 14 TCP and 3 UDP connections made from the Yamaha receiver to some hosts in the Internet during my capture:

All TCP connections are going to these four different IPv4 addresses seen in the DNS queries. (1) Three TCP connections are made BEFORE I did something at all, they are initiated directly after I powered the device on. However, they are only going to vTuner and not to Yamaha itself. Furthermore they do not really transfer any information except an “EncryptedToken”. At least the requested URL transfers the MAC address in an obfuscated way. (And I do not even know which kind of obfuscation it is using here. Do you?) I am not quite sure whether this is good or bad.

(2) Then I started to walk through my bookmarks on the receiver itself. It requested the same URL again but got some responses, followed by some more HTTP streams through “/asp/browsexml/FavXML.asp?…” locations. It finally got the streaming URL for my requested radio station, ERF Pop: “c14000-l.i.core.cdn.streamfarm.net/14000cina/live/2908erfpop/live_de_96.mp3“:

For some reasons the receiver terminated its first connection to the stream in which it used the following user agent:

While it immediately reconnected to the same stream with the following user agent and one more HTTP statement:

This stream was alive until I terminated it. One more outgoing connection to “item.radio456.com” downloaded a logo from the radio station. The following two screenshots show the actual connection to the stream and the logo download:

(3) Finally, the three UDP connections are for NTP to “primary13.vtuner.com” host again:

Connections from the iPhone App

Now I used the Yamaha NP Controller app on my iPhone to control the receiver. (Shit, I do not know how the app initially found the IPv4 address of the receiver. I can see many direct TCP connections to the IP but I am not quite sure how the app got it. Maybe through some MDNS or SSDP sessions. Or it was already in the cache of the app?!?) I browsed through my bookmarks again, (hence the receiver initiated some connections to the Internet again and transferred the bookmarks to the app on my smartphone) and I changed the loudness and the input source of the receiver. In summary I captured 8x HTTP connections to port 80 on the receiver and 1x connection to port 8080. All used the POST method while the connections to port 80 POSTed into a /YamahaRemoteControl/ctrl path while the connection to port 8080 (UPnP?) POSTed into /AVTransport/ctrl:

Connections to/from my Router

Another big part in my trace were the communications between the Yamaha network receiver and my local router. I was not aware that these devices themselves are that chatty. My home router is an AVM FRITZ!Box 7430 with FRITZ!OS 06.83. It seems to be heavily related to UPnP since it uses SSDP (simple service discovery protocol) not only to some multicast addresses but also directed between the router and the network receiver. In summary I have the following connections between those two devices: 50x TCP and 2x UDP. The TCP connections are to the ports 80, 8080, 49000, and 51108, the UDP ones to 4996 and 49840.

The following four screenshots show 1) an overview of the connections between those two devices, 2) one directed SSDP from the router to the Yamaha receiver, 3) one TCP 49000 stream from Yamaha to Fritzbox, and 4) vice versa to TCP 8080 from Fritzbox to Yamaha:

Firmware Update

In another trace I analyzed the firmware upgrade process. (Not the firmware itself.) The DNS query was made for  avpro.global.yamaha.com ( Seven TCP sessions to port 80 with unencrypted HTTP were used from the receiver to download the firmware. Different “FIRMxx.bin” files were downloaded.

Extracting the URLs from the streams you get the paths such as: http://avpro.global.yamaha.com/2013/R0346/FIRM01.bin. In summary the download took about 12 Mbytes. However, the firmware image seems to be encrypted enterily, as binwalk -E FIRM01.bin reveals (since the entropy is very close to 1 which is almost everytime a sign of encryption):


It’s not trivial to analyze an unknown trace even though this one is not big in size at all. I am sorry, but since it’s not my main job (but only my hobby) to deeply analyze trace files with protocols as MDNS, SSDP, and RTP, this blogpost might lack certain details.

Without any user interaction the Yamaha network receiver initiates a few connections to the Internet, namely to vTuner from which it requests the time via NTP and sends a basic “I am alive” packet which unambiguously transfers the unique MAC address of the receiver. For sure, this won’t create real user profiles, but at least it’s more than nothing. At least it does not transfer any more details about the user such as listening profiles. Since the Internet radio bookmarks are stored at vTuner anyway, the receiver must download them accordingly. For this, the usage of the MAC address as single authentication method via unencrypted HTTP is not a good choice at all.

Featured image “For Sale!” by Tekke is licensed under CC BY-ND 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked *