The day started just after midnight with a firmware update that put my GL.iNet Beryl 7 into a reset loop. It's a small travel router, already on my tailnet at x.x.176.3 under the name gl-mt3600be, sitting on its old LAN gateway of x.x.8.1 in repeater mode onto my own network. Once the reset loop cleared I spent the next couple of hours turning it into something else: a Tailscale subnet router for a hotel client's IPTV headend, which runs as its own isolated island with no cable into the hotel's actual network.
The changes were small individually. LAN address changed, DHCP server turned off so the headend server stays the only one handing out addresses. AP Isolation got considered and rejected: it only stops wireless clients talking to each other. It leaves the wired LAN wide open, so it does nothing to protect the island. Hotspot SSIDs off on every band. Route approved in the Tailscale admin console. A daily 4am reboot scheduled instead of weekly. None of it was tested against anything real yet. That came the next afternoon, on site.
Racking a tuner, chasing cables with no obvious answer
I plugged the Beryl into the LAN port of the hotel's H3C switch, and immediately couldn't reach its own login page except over cellular data. The subnet mask on my Mac's USB ethernet adapter had drifted to 255.255.0.0, which meant my laptop treated two separate /24s on the isolated network as one and TCP connections to the server's management address quietly never completed, even while ping worked fine. That took a while to notice and longer to fix, because ping lying to you about the actual problem is exactly the kind of thing that wastes an afternoon.
Once that was sorted, the physical work started. The tuner got racked, and there was a brief back-and-forth about where it should sit relative to the Omada switch and the server, before realising the server is actually the deeper unit of the two. I found a handful of splitters around the rack labelled TAP instead of the usual in/out, which I hadn't seen before and didn't have an answer for on the spot. Photos went out for identification of the aerial plant on the roof, and the tuner's admin login turned out to still be on its factory default, which goes on the list to change before handover.
The tuner locks onto real Perth channels
This was the actual milestone of the day: getting the tuner locked onto a real broadcast signal instead of the demo channels used on the bench the day before. Set to DVB-T at 7 MHz, it locked five multiplexes off the hotel's existing rooftop aerial, at 23.05 Mbps each, signal quality 99%, zero bit errors: 177.5 with 9 programs (the Seven Network), 184.5 with 15, 191.5 with 10, 219.5 with 9, and 226.5 with 16. Fifty-nine programs available, though only the first mux got wired through today.
Wiring one mux through meant setting the tuner's multicast output, adding a protocol conversion entry on the server pointing at that multicast address with HLS as the output, starting distribution, and syncing the new programs into the package assigned to the set-top box. I was missing one frequency entry on the second tuner the first time through, which is why nothing showed up until that got added. After a reboot of the box, all nine Seven Network channels appeared in the list and played. That's the whole path working end to end: rooftop aerial into a tuner, tuner into the server, server out as HLS, set-top box tuning individual channels, on the client's actual signal.
Two hours chasing a fault that wasn't there
The other half of the day was less satisfying. The server's data address and its admin port on 8160 both looked dead, even after a reboot of the server itself, and I got as far as drafting a fault report to send to the vendor. Neither cause turned out to be the server. First, Tailscale had picked up the /24 the Beryl was advertising, so my own traffic to the server was going out over the hotel's guest wifi and back in over the tunnel, which is why ping still worked but showed inflated times and a lower TTL than it should have. Second, the netmask on my laptop's ethernet adapter had gone back to 255.255.0.0 again, silently collapsing the two subnets into one, so a TCP handshake could no longer complete even though an ICMP echo still could. I found the netmask myself, going through the interface settings line by line instead of assuming ping's success meant the link was fine.
Along the way I also learned that a manual static route added with route -n add -host ... -interface en6 on macOS points the link-layer address at the Mac's own adapter, which broke the connection further instead of fixing it, and that macOS doesn't have timeout, so tcpdump -c N is the substitute.
Before wrapping up on site, I had the session note down everything that mattered for the runsheet: the working addresses, the add-a-channel steps, and the traps I'd just hit, all written into a new runsheet kept inside the client project instead of the general lab runsheets, since this is client work that travels with the engagement. Session saved, closed, and picked back up later that evening from home, where I tried to get back into the IPTV server over Tailscale again. My PC showed the router offline while my phone showed it online, which didn't get fully resolved before I stopped for the night; the router's own admin script for advertising routes was still being checked against its config when I left it. In between, I also asked for some agents to go pull higher-resolution photos of the hotel from its own public website, since the images on the client project so far are too small to use for anything. That didn't get finished either.