Starlink User Terminal Teardown

Original Article ↗ Hacker News Discussion ↗

Userspace packet processing and performance

  • Discussion centers on the claim that all packets are processed in userspace in a DPDK‑like stack.
  • Some are surprised, doing back‑of‑the‑envelope math: 1 Gbps of 100‑byte UDP is ~1M packets/s, giving ~1000 CPU cycles/packet at 1 GHz.
  • Others argue this is reasonable: Starlink’s actual bandwidth is lower (cited 25–200 Mbps) and average packets are much larger, so the real packet rate is far more manageable.
  • Userspace forwarding can reduce buffer copies and be faster than kernel networking if the NIC queues are mapped directly into userspace.
  • There is debate about how much is handled in software vs hardware offload; some say >100 Mbps typically relies heavily on offload, others note many CPU‑only routers at that speed exist.
  • Zero‑copy through the kernel is mentioned as possible, but harder to set up than a DPDK‑style design.

SSH keys, remote access, and privacy

  • Firmware writes 41 SSH public keys into root’s authorized_keys, with SSH open on the LAN.
  • Commenters compare this to ISP CPE remote management (e.g., TR‑069) and note that ISPs can already capture traffic in the core, but here Starlink also gains access to the local LAN.
  • Concerns include access to NAS shares, cameras, printers, device lists, and local metadata like cast titles and torrent hashes, even if internet traffic is encrypted.
  • Some users mitigate by isolating Starlink or ISP gear behind their own firewall or DMZ.

Why 41 keys? Key management approaches

  • Speculation that 41 may correspond to points of presence or management partitions; others suggest it’s simply many admins/devices.
  • Several people argue this is poor practice: many long‑lived keys create numerous compromise points and are hard to revoke at scale.
  • Alternatives proposed:
    • SSH certificates with a small number of trusted CAs issuing short‑lived certs.
    • Intermediate management gateways instead of direct per‑admin access.
    • Strong compartmentalization so each key controls only a limited subset of terminals.
  • There is disagreement on when certificates become necessary versus “just” managing authorized_keys files.

Bring‑your‑own modem/router and regulation

  • Large subthread compares Starlink’s model to terrestrial ISPs:
    • In many EU countries, regulation either requires or strongly encourages free choice of terminal equipment, with examples where users plug routers or SFP ONTs directly into fiber.
    • Others argue that modems/ONTs remain part of the ISP’s network, and operators still control firmware and provisioning (DOCSIS configs, GPON OMCI, TR‑069, etc.).
  • In the US, commenters say ISPs must allow user‑provided cable modems if technically compatible, but those modems still receive ISP‑controlled firmware.
  • Some note Starlink allows/needs user routers for certain features (e.g., IPv6), but the satellite modem itself is not user‑replaceable.
  • There is disagreement over how much legal leverage regulators have over a global satellite operator; some say Starlink must still comply with local law, others argue jurisdiction is harder to enforce.

Starlink addressing and NAT

  • One commenter briefly outlines Starlink’s addressing:
    • IPv6 via DHCPv6 Prefix Delegation (/56).
    • IPv4 via multiple layers of NAT (NAT44444) and CGNAT, with separate internal ranges for the dish, router, and ground‑station network.

Firmware security vs openness

  • A question is raised about how to prevent reverse‑engineering in products.
  • Proposed defensive techniques include:
    • Encrypted root filesystems with secrets in secure elements.
    • Using TrustZone or similar to protect boot, decryption, and signing logic.
  • Others point out that in this teardown, the filesystem could simply be dumped, implying weak or absent protections beyond the bootloader.
  • A counter‑view strongly discourages heavy lock‑down:
    • It consumes engineering effort, may clash with GPL obligations, and harms power users who could extend or fix products themselves.
    • Unless there is a clear, strong threat model, openness and invest­ment in actual product quality is presented as the better trade‑off.

Reverse engineering and emulation techniques

  • People discuss how to emulate firmware that expects external devices (e.g., GPS):
    • Suggestions include QEMU, Renode, and commercial platforms like Arm FVP and Intel SIMICS.
    • The Android emulator is referenced as an example of QEMU extended with emulated sensors and radios.
  • Basic RE workflow described: buy device, open it, look for UART; if none, desolder flash (eMMC) and dump contents.
  • There is interest in general guides for building such emulation and test environments rather than ad‑hoc approaches.

Miscellaneous

  • Minor nitpicking of a “Ternimal” typo in the article title.
  • Clarification that the firmware stack is OpenWrt‑based, not shared with rocket software, though some speculate it might share code with satellite telemetry systems.