HDHR Win10 App 20230110 (1.1.399.0) not displaying on DVR PC

[mike808]

Hmm. Now https://ipv6-api.hdhomerun.com/discover returns the expected JSON response with tuner URLs, and https://ipv4-api.hdhomerun.com/discover returns an empty JSON set.

Interesting thing about ipv6-api response, the tuners have IPv4 URLs while the storage (i.e. the HDHR DVR service) has IPv6 URLs.
Even more interesting, pasting that IPv6 URL into the browser actually works in FF 107.0!
As in: http://[2600ed7:6100:####:####:####:df33]:33642/discover.json

[mike808]

Fired up Wireshark. I'm seeing a connection from the HDHR Record service to something, I'm guessing one of the HDHR devices. I'm not sure which, since the ipv6 discovery only displays the IPv4 addresses of the tuners, not the IPv6 addresses.

The connection is clearly attempting HTTPS since the destination port is 443. It appears to succeed as there is some encrypted application data that comes back.
Source Address: HDHR Record (2600ed7:6100:####:####df33)
Destination Address: 2606:4700:20::681a:dd5 (2606:4700:20::681a:dd5)
So, when I try to display https://[2606:4700::6812:dad]/ in FF, I get this error:

Code: Select all

An error occurred during a connection to [2606:4700::6812:dad]. 
Cannot communicate securely with peer: no common encryption algorithm(s).
Error code: SSL_ERROR_NO_CYPHER_OVERLAP

Hmm. When I try to visit the regular http://[2606:4700::6812:dad]/ (non-TLS) URL, I get a Cloudflare direct IP access not allowed.
So this is maybe my internal DoH to 1.1.1.1 resolver?

Further down, I'm seeing the HDHR Record device try to ping (ICMPv6) my EXTEND (DeviceID 10522C9A) which has the IPv6 address of 2600ed7:6100:218:ddff:fe05:22c9 (which matches "0522c9"). And Wireshark says the Destination SLAAC MAC address is "Silicond_05:22:c9". Shortly after, I see another ICMPv6 exchange with fe80::218:ddff:fe07:40d6, and matches my QUATRO (DeviceID 10740D6C).

However, the QUATRO tries to ping 2600ed7:6100f6264001, which I'm not sure what that is. Maybe another IPv6 device on my network saying "hello" back.

When I stopped the HDHR View app, Wireshark marked a connection from HDHR Record to https://[2606:4700:20::681a:dd5]/ in red, so I think that's the connection that is hanging/failing. And when I try that in my FF browser, I get the same SSL_ERROR_NO_CYPHER_OVERLAP.

So I think that's getting me much closer to the root cause. I'll see what some TLS debugging can give me.

[mike808]

Just for fun, it looks like entering the IPv6 address of the tuner in FF works.

Code: Select all

http://[2600:1700:ed7:6100:218:ddff:fe05:22c9]/discover.json

It returns the JSON just like the IPv4 version.

Still no luck on debugging/decrypting the Client Hello and the server response. It seems to be returning a record type 0x15, not 0x16 (which is a server hello).

[nickk]

2606:4700:20::681a:dd5 is CloudFlare (our CDN provider).

Follow the TCP stream relating to the "no overlapping ciphers" packet, then check the Client Hello packet - it will list the ciphers your side is reporting support for.

Nick

[mike808]

I later figured out that the IPv6 address was for Cloudflare by visiting the regular http version and I get a basic Cloudflare "nothing to see here, move along" kind of error page.

Decoding a TLSv1.3 Client Hello packet by hand is not fun. I suspect there's something I'm missing in the spaghetti of registry settings around this stuff. There are Microsoft knowledgebase articles about cipher suite priorities, but they're all for server versions, not for your basic Windows 10 Home, so it is hard to tell what applies and what doesn't. And we wonder why average consumers (who don't run Server versions of Windows or manage AD forests - no GPD policy editor) are easy pickings for the bad guys.

I'll keep plugging away. I must have flubbed something on this box that I didn't on the others locking out the older protocols and I haven't spotted it yet.

[nickk]

the Client Hello packet will list the ciphers your Windows system supports...

[mike808]

I fired up Wireshark and captured a bit, launched the HDHR View app, waited a bit (still black screen of death, no debug info or indications anything is happening and no response in the app other than the hamburger), and then shut it down. Saved the pcap file.

Digging through it, all I can see are ARPs and ICMPs (pings) between the two tuners and the DVR, along with some DVR traffic to Cloudflare, which was noted is SD's CDN (probably for guide data and/or telemetry). The DVR traffic seems to all be successful TLSv1.3 connections.

What I don't see are connections that are what I can tell are from the HDHR View app to anything. I definitely am NOT seeing any failed TLS handshake connections. And yet it works from the other PCs. Just not the one the DVR is running on.
This was on HDHR View build 398 (20221213) and the HDHR Record software from 20221205.

[mike808]

Well, I tried uninstalling the HDHomeRun View app and ran into a problem with the store not able to reinstall it. Pressing "Install" didn't do anything, comes right back to "Install". I had to manually get the store links (via https://store.rg-adguard.net/ and pasting in the store URL from the download page, selecting "Retail", downloading the EF712BA7.HDHomeRunDVR_1.1.399.0_neutral_~_23nna27hyxhag.AppxBundle app bundle, and manually installing via PS Add-AppxPackage command.

Now I have the app back, but the behavior is still the same. A blank screen with only the hidden hamburger menu functioning. I fired up Wireshark and captured the interface, launched HDHR View, got the black screen of death, closed the app and then closed the wireshark capture. Looking through the WS npcap, it looks like the app is connecting to the UI servers and I see the recording engine talking to the tuners. But I don't see any failed network connections from the app, as far as I can tell. Happy to upload the npcap if I'm missing something. There does not appear to be a TLS issue/error, so I don't think that's a factor anymore.

Is there some application logging I can see in Windows event logs somewhere? Any pointers on what to filter for and which event logs?

The HDHomeRun View app works exactly as it should from any of the other local PCs. I'm on a router-behind-a-router setup with AT&T. My RG is on the 192.168.1.x subnet and my router (Asus RT-AC68R) is on the 192.168.2.x subnet. It looks like the Quattro is operating on IPv6 and IPv4, but the Extend is only operating on IPv4. I can view all of the tuners launching VLC via the HDHomeRun Config GUI app.