Investigation in Isolation: Silicondust HDHomeRun PRIME

Aside: a day after my last post, I was reading Fumbling the Future (a great tale of the amazing Xerox PARC lab) and one of the chapters is titled "Research: the Harvest of Isolation." Pretty cool!

The second in my Investigation in Isolation series is the HDHomeRun PRIME by Silicondust. This little gadget is a network-attached TV tuner. I use Verizon FIOS at home, and while I'm satisfied with the service the offer, I had a pretty awful experience with their support team that made me want to replace their "Quantum Gateway" CPE router. (Long story short: a support technician overstepped his bounds and was snooping around my home network.) Naturally, as a founding member of 128 Technology, Inc., the choice for my router replacement was self evident.

Swapping out the FIOS router for your own router isn't the easiest of tasks. While you save the $12/month rental fee for their Quantum Gateway, you lose a lot of their TV functionality – notably, the on-screen guide and video on demand. Instead of the $12/month router, I decided to pay $7/month for a CableCARD and picked up a used HDHomeRun PRIME3 on eBay.

Here's the thing about the HDHomeRun: they no longer make a CableCARD-equipped TV tuner, having discontinued the PRIME3 a few years ago. There simply aren't any new ones anymore. The replacement, the PRIME6, has been "coming soon" for years, with release dates continuously slipping. So the PRIME3 sells for a premium on the aftermarket. I bought mine for about $150, though you can get lucky and buy them cheaper than that now.

I must say, I have been extremely impressed by this device. The setup was easy and painless (it used DHCP to acquire an address, and had a very simple setup page). The picture quality is perfect on our Apple TV, although watching HD channels on my iPhone can sometimes lag. The biggest selling point for me is the ease of integrating it with my Apple TV using the Channels app. It's not by Silicondust, but works perfectly in conjunction with it, and has a very elegant and intuitive UI that makes the FIOS on-screen menu look like it's 8-bit.

Like last time when I dissected the WeMo, I turned packet capture on for the HDHomeRun for a few days and let it simmer. I pulled down the captures and picked through them to see what made it tick. Here's what I found.

Protocols on the Wire

In my investigation, I saw the following types of packets:

  • DHCP. Notable only in that the HDHomeRun sets the broadcast bit of the DHCP request, forcing the DHCP server to broadcast the reply. This is discouraged behavior (per RFC 1531 section 3.1.1).
  • IGMPv3, to join 224.0.0.251 and 239.255.255.250. Standard stuff for IOT.
  • SSDP
  • ARP. Notable because the HDHomeRun sends a LOT of ARP messages, including to devices I would not normally expect it to be sending ARP messages to.
  • DNS
  • HTTPS, for outbound requests to Silicondust's cloud service
  • HTTP, for inbound requests

DNS/HTTPS Connections

I monitored DNS traffic on my network for a week, filtering for anything emitted by the HDHomeRun. There were only two addresses it reached out for: location-api.hdhomerun.com and tuner-api.hdhomerun.com. The same sequence of events repeats itself every four to eight hours (with no regular cadence I could discern), and is basically as follows:

  1. A DNS request is sent for location-api.hdhomerun.com.
  2. The device sends an HTTPS request to the remote server and receives about 4K in data in return. This presumably is the location for the TV guide data.
  3. A DNS request is sent for tuner-api.hdhomerun.com, which is a CNAME for api.silicondust.net.
  4. The device sends an HTTPS request to the remote server and receives (in my case) 55K of data, presumably the television programming information. The amount of information downloaded in the ten separate instances I captured were all 55K, irrespective of whether the last download had happened four hours earlier or eight hours earlier.

HTTP Client Connections

When a client application (in my case, Channels) wants to watch TV via HDHomeRun it will connect using HTTP and GET /discover.json. This connection is brief; HDHomeRun will close the connection. In my testing, the client would immediately reconnect and issue a second GET /discover.json, the only difference between the first and the second is the Accept: header is different; in both cases, the HDHomeRun's response is the same.

Next, the client sends an HTTP request to GET /lineup.json. This returns the channel lineup (55K, coincidentally) back to the client. In my test, I selected a channel and clicked on it, which then caused the client to issue another HTTP request to TCP/5004; my device has three tuners, and this request was apparently directed at tuner 2 based on the HTTP URI /tuner2/v544. (The channel I was accessing may very well have been channel 544.) The 200 OK indicates the codec used is avn1.640040, and this is followed by the streaming video over TCP.

Note: this avn1.640040 means it's using the H.264 codec, and the 640040 are arcane H.264 parameters referencing profile_idc, constraints_set, and level_idc. This translates in my case to "High profile" and much more math/research than I'm willing to invest into the arcane H.264 ITU standard.

Securing my Traffic

Because I only use this HDHomeRun from the Apple TV that shares the same LAN, I am constraining the device's internet access to limit it to downloading the channel guides and lineup information data from the Silicondust cloud service. This means a service that looks like the following on my 128T:

admin@labsystem1.fiedler# show config running authority service HDHOMERUN

config

    authority

        service  HDHOMERUN
            name                  HDHOMERUN

            applies-to            router
                type         router
                router-name  newton
            exit
            description           "HDHomeRun access to Silicondust"
            scope                 private
            address               tuners-api.hdhomerun.com
            address               location-api.hdhomerun.com
            address               api.silicondust.net

            access-policy         iot
                source      iot
                permission  allow
            exit
            share-service-routes  false
        exit
    exit
exit

I've given access to the entire iot tenant for now, because I haven't yet carved the HDHomeRun device into its own tenant. That will be an exercise for another day, when I undergo the next phase of my own local network redesign.

Future Work

Like the WeMo post from last week, there's more to learn and investigate with the mDNS and UPnP/SSDP transactions flying around. This will be in my sights for a near-term blog post.

Conclusion

Hey, I really, REALLY like this gadget. It seems to be pretty well behaved (with a few quirky behaviors around DHCP and ARP), and has been very reliable for me. Recommended!