Aðaldalshraun All-Sky Camera

News: February 2026

Sorry for a late update but I've been tinkering with satellite Internet.

When I first introduced Starlink into the setup, the intention was simple: replace the 4G connection as the main backbone and gain more upstream bandwidth. On paper it should have been an upgrade. In practice, it introduced a layer of complexity that the existing system had never been designed around.

The original architecture was straightforward: one WAN connection, one default route, predictable packet flow.

As soon as Starlink was added alongside the 4G router, both devices began advertising themselves as the default gateway via DHCP.

The Linux servers then had competing routes to the internet. Even with metrics adjusted, this created asymmetric routing conditions — packets could leave through one interface and responses return through another.

The result was intermittent stream drops, SSH instability, VLAN visibility issues, and behaviour that felt random.

It wasn’t that Starlink was malfunctioning; it was that two WAN routers were competing without proper policy routing in place.

Starlink also behaves differently from 4G at the network level.

It operates behind CGNAT and has variable latency characteristics compared to the relatively consistent 4G link.

For everyday browsing and downloads, that variability is irrelevant. For a long-running RTMP ingest to YouTube, however, consistency matters more than raw bandwidth. In this case, the slower but steadier 4G connection proved more predictable for continuous streaming.

Perhaps the biggest impact wasn’t technical but architectural. Adding Starlink expanded the system from a simple single-WAN model into a dual-WAN, VLAN-segmented environment requiring routing controls, MAC rules, firewall adjustments and careful interface management. The mental model shifted from “plug and run” to “actively managed multi-path routing.” That increase in complexity amplified instability and made troubleshooting far more difficult.

To be fair Starlink itself wasn’t the root cause of the streaming failures — introducing Starlink as a parallel backbone exposed existing weaknesses in routing design and increased system fragility.

It's well suited for client bandwidth and general use, but in this setup it required deliberate routing policy and separation from the server’s primary WAN role.

The lesson wasn’t that Starlink failed; it was that complexity grew faster than control.

So currently the Starlink is running in isolation, just for streaming entertainment and a faster internet connection for laptops.

I'm taking a trip to the UK next week and I have a hardware shopping list. But for now all seems back to normal

As always, if you're in the north drop me a message. You're welcome to pop in for a coffee (bring cake)

geimfarinn@netnurds.com