GUI Config Can't find Tuner??

[def1149]

I have an HDFX-4K runing the latest firmware 20261107

HDHomeRun Setup can find the tuners
HDHomeRun Windows 11 app can find the turner and play
Channels DVR can find the tuner and play and record tuner channels
Channels clients on Google Streamer find and play tuner channels

HDHomeRun GUI Config can't find the tuner ??

HDHomeRun Config GUI

ERROR: communication error

I've installed the most recent app package

I'm not 100% certain because I didn't do an explicit before and after test, but this seems to be related to the 20261107 firmware

[jasonl]

We're not seeing any issues here. Are you able to get a network packet capture using Wireshark of opening the Config GUI software and send that to support at silicondust dot com so we can review?

[def1149]

OK I'll give it shot

..........Desktop ....................Tuner
Filter: host 192.168.1.50 and host 192.168.1.35

All I see are ping and ARP packets, and responses between my desktop and the tuner
I use Pingman Multiiping to monitor connectivity to key endpoints
When I load the Config GUI, there is no traffic at all ???
It's not even trying to connect

Update: I checked the installation directory and found a command-line version of config.

C:\Program Files\Silicondust\HDHomeRun>hdhomerun_config discover 192.168.1.35
hdhomerun device REDACTED found at 192.168.1.35

[jasonl]

Try ip.dst==255.255.255.255 || ip.dst==192.168.1.35 || ip.src==192.168.1.35

[def1149]

I can also connect to the tuner http://192.168.1.35 and there are no errors in the tuner log

What am I looking for?

No. Time Source Destination Protocol Length Info
3377 12:27:17.5629073 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
8762 12:27:19.6104535 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
8763 12:27:19.6111725 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
12638 12:27:21.4543103 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
12680 12:27:22.2769775 192.168.1.173 255.255.255.255 UDP 86 65506 → 65506 Len=44
12822 12:27:23.7061433 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
13016 12:27:25.5516498 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
13111 12:27:27.5972510 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
13242 12:27:28.4463125 192.168.1.50 192.168.1.35 ICMP 70 Echo (ping) request id=0x0002, seq=1511/59141, ttl=129 (reply in 13243)
13243 12:27:28.4520040 192.168.1.35 192.168.1.50 ICMP 70 Echo (ping) reply id=0x0002, seq=1511/59141, ttl=63 (request in 13242)
13254 12:27:28.5507965 192.168.1.50 255.255.255.255 UDP 56 50121 → 65001 Len=14
13264 12:27:28.7579312 192.168.1.50 255.255.255.255 UDP 56 50121 → 65001 Len=14
13295 12:27:29.0827308 192.168.1.50 255.255.255.255 UDP 62 50122 → 65001 Len=20
13307 12:27:29.2977812 192.168.1.50 255.255.255.255 UDP 62 50122 → 65001 Len=20
13316 12:27:29.4420671 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
13503 12:27:31.4885829 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
13528 12:27:31.9681642 192.168.1.50 255.255.255.255 UDP 62 50123 → 65001 Len=20
13537 12:27:32.1765886 192.168.1.50 255.255.255.255 UDP 62 50123 → 65001 Len=20
13693 12:27:33.5386026 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
13771 12:27:34.8492675 192.168.1.50 255.255.255.255 UDP 62 50124 → 65001 Len=20
13901 12:27:35.7923467 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
14121 12:27:37.5333306 192.168.1.50 255.255.255.255 UDP 62 50125 → 65001 Len=20
14123 12:27:37.6326453 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
14124 12:27:37.7341164 192.168.1.50 255.255.255.255 UDP 62 50125 → 65001 Len=20
14237 12:27:39.4758852 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
14446 12:27:41.3804845 192.168.1.50 255.255.255.255 UDP 56 58494 → 65001 Len=14
14458 12:27:41.5917413 192.168.1.50 255.255.255.255 UDP 56 58494 → 65001 Len=14
14467 12:27:41.7304212 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
14673 12:27:43.4578295 192.168.1.50 192.168.1.35 ICMP 70 Echo (ping) request id=0x0002, seq=1517/60677, ttl=129 (reply in 14674)
14674 12:27:43.4757336 192.168.1.35 192.168.1.50 ICMP 70 Echo (ping) reply id=0x0002, seq=1517/60677, ttl=63 (request in 14673)
14680 12:27:43.5718657 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45
14882 12:27:45.6217018 192.168.1.147 255.255.255.255 UDP 87 2525 → 59387 Len=45

[jasonl]

No response is being received to the broadcast discovery. Are you running any third-party firewalls on the PC?

[def1149]

No add-on firewall

The router is a GL-iNet GL-MT6000 running OpenWRT. The tuner is connected to the Ethernet port on a GL-MT3000 running in wireless bridge mode locked to 5 GHz because I can't run a cable to the location of the tuner.

Except for this problem, everything works great

There may be a firewall configuration problem on the MT-3000.
Will investigate and report back

OK, after working with my network guru, ChatGPT, we found and solved the problem. It was firewall rule gibberish

Root cause: The MT3000's WAN masquerading rule was replacing the HDHomeRun tuner's source IP (192.168.1.35) with the MT3000's IP (192.168.1.210).

Solution: A narrowly targeted NAT exception in /etc/firewall.user preserves the tuner's source address for UDP discovery responses on port 65001.

Thanks for the lead on which rabbit hole to descend into.
-
Update #2, The final solution. Update the firmware on the MT-3000 to a generic version of OpenWRT that supports WDS and no funky settings were needed. I had previously updated the MT-6000. Now I have clean layer-2 bridging over Wi-Fi