How to modify Starlink Mini to run without the built-in WiFi router

Speculated use cases and wartime context

• Many infer the modification is aimed at power‑constrained, mobile wartime applications: long‑range explosive drones, “Nemesis” night bombers, “Magura” sea drones, or front‑line comms where every watt and gram matter.
• Concerns are raised that Starlink can track and remotely disable such uses; others note they mostly haven’t, and alternatives with similar bandwidth/latency are scarce.
• There is debate over previous incidents in Crimea: some frame them as Musk arbitrarily cutting service; others argue they followed pre‑agreed geofencing and US export/sanctions constraints.
• Discussion expands into geopolitics: Viasat terminal bricking at the war’s start, Iridium vs Starlink capabilities, NATO’s reluctance to escalate with Russia, and Europe’s past dependence on Russian gas.
• Some worry that publicly blogging and YouTubing such military‑adjacent hacks paints a target on engineers; others see it as a risk intrinsic to contributing to a war effort.

Geofencing, disablement codes, and possible circumvention

• The article claims the user terminal doesn’t know about plans, regions, or speed limits; it just follows commands and reports “disablement codes” from the satellite.
• Commenters debate whether this implies restrictions could be bypassed locally; consensus leans toward enforcement being done in the network, with codes only for diagnostics and app UX.
• Some report Starlink use in occupied Ukrainian territories and parts of Russia (especially via RV/roaming plans), others insist geofencing is strict and only occasionally leaks at borders.
• One idea: treat disablement codes as sensors on autonomous platforms (e.g., if “blocked by obstruction” or “unlicensed country,” a drone could change altitude, route, or comms mode).

Hardware design and Ethernet vs RGMII

• Several are intrigued that the internal board‑to‑board link uses fully modulated Ethernet rather than a lighter MAC‑to‑PHY interface like RGMII/SGMII.
• Arguments for Ethernet: easier prototyping (can plug into a laptop), more robust over cheap connectors, flexible modularity between “modem” and “router” boards, and independent upgrade paths.
• Arguments against: extra A/D–D/A conversions and silicon cost vs a direct digital link. Some note RGMII/SGMII need tight signal‑integrity constraints, which are harder board‑to‑board.
• Questions arise why hack the unit at all, given an existing RJ45 port and software Wi‑Fi disable; answers cite weight reduction, guaranteed RF silence, lower power draw, and removing the router/NAT entirely.

SoC and networking aspects

• The terminal reportedly uses a MediaTek SoC.
• Some wish Starlink offered a clean dish+modem product with real public IPv4; others explain CGNAT as a necessity given IPv4 scarcity. Tunneling to get a public address is mentioned as a workable, if imperfect, workaround.