1 Punkte von GN⁺ 2025-06-16 | 1 Kommentare | Auf WhatsApp teilen
  • Starlink Mini 1 kann durch Entfernen des integrierten Wi-Fi-Routers als reines Ethernet-Endgerät betrieben werden, was mehr Optionen für individuelle Netzwerkkonfigurationen oder Embedded-Installationen eröffnet
  • Der Umbau gilt mit Stand 14. Juni 2025 ausschließlich für Starlink Mini 1; bei späterer Hardware wie Mini 2 passt das Verfahren möglicherweise nicht
  • Die Metallplatte auf der Starlink-Platine dient beim Zerlegen als Kühlkörper und EMI-Abschirmung; wird sie entfernt, steigt das Risiko von Throttling oder elektromagnetischen Störungen
  • Hauptgerät und Router sind über einen 1-Gbps-Ethernet-Link und einen 12-VDC-Strombus verbunden; bei eigenen Designs ist anders als bei der kurzen internen Direktverbindung ein Ethernet-Transformator erforderlich
  • Nach dem Entfernen des Routers stellt das Endgerät im Netz 192.168.100.0/24 DHCP und ein gRPC-Status-Interface bereit; für mehrere Geräte nach der Satellitenverbindung ist jedoch ein vorgeschalteter Router nötig

Umfang des Umbaus und Hinweise zum Zerlegen

  • Starlink Mini ist ein All-in-one-Endgerät mit integriertem Wi-Fi-Router, kann aber nach physischem Entfernen der internen Router-Platine als reines Ethernet-Gerät betrieben werden
  • Der Anwendungsbereich ist mit Stand 14. Juni 2025 Starlink Mini 1; Hardwareänderungen bei künftigen Modellen wie Mini 2 können das Verfahren ungültig machen
  • Das Zerlegen erfordert Geduld und Präzision; empfohlen werden ein Metallspudger und Kunststoff-Hebelwerkzeuge
  • Zum Entfernen der Router-PCB wird ein dünnes, flexibles Messer oder ein dünner Metalldraht benötigt
  • Nach dem Entfernen der Router-PCB kann die Demontage beendet werden; vom Entfernen der Metallplatte der Starlink-PCB wird dringend abgeraten
    • Die Metallplatte dient zugleich als Kühlkörper und als EMI-Abschirmung
    • Die Starlink-CPU erzeugt viel Wärme; bei unzureichender Kühlung können CPU oder Antennen-Array gedrosselt werden
    • Die Kanten der Metallplatte sind mit leitfähigem Klebstoff befestigt, was die elektromagnetische Abschirmung unterstützt; beim Entfernen können erhöhte Emissionen und Störungen benachbarter Elektronik auftreten

PCB-Steckverbinder und Pinbelegung

  • Der genaue Steckverbindertyp auf der Starlink-Mini-PCB ist nicht bekannt und könnte eine kundenspezifische Anfertigung sein
  • Das Steckverbinder-Raster beträgt 2 mm, daher könnte ein standardmäßiger 2-mm-Header passen
  • Der Steckverbinder ist mit leitfähigem Klebstoff und einer großen Massefläche fixiert; über dem Steckverbinder auf der Router-PCB befindet sich eine Abschirmung
    • Diese Konfiguration dient der EMI-Unterdrückung
  • Zwischen Hauptgerät und Router wird ein 1-Gbps-Ethernet-Link verwendet
  • Die interne Verbindung ist eine direkte PHY-zu-PHY-Verbindung mit etwas Entkopplung, ohne Ethernet-Transformator
    • Auf kurze Distanz ist das zulässig, bei eigenen Installationsdesigns ist ein Ethernet-Transformator jedoch zwingend erforderlich
  • Der grundlegende Strombus ist 12 VDC
  • Die Pins 11, 14, 16, 17 und 18 werden bei diesem Umbau derzeit nicht verwendet und dienen hauptsächlich dem Starlink-Router-Monitoring
  • Für eine stabile Stromversorgung wird empfohlen, alle 12-VDC- und GND-Leitungen zu verwenden

Design für direkte Ethernet-Verbindung

  • Das Beispiel für eine direkte Ethernet-Verbindung verwendet eine Schaltung, die die für den PCB-Steckverbinder des Starlink Mini 1 nötige Ethernet-Isolation und minimale Stromfilterung bereitstellt
  • Um den U1-Steckverbinder herum wird eine Guard-Masse empfohlen
  • Ein optimales Design umfasst leitfähigen Klebstoff und Abschirmung
  • Die Leiterbahnen zwischen Steckverbinder und Ethernet-Transformator sollten so kurz wie möglich gehalten werden
  • Der normale Betriebsstrom bei 12 V beträgt etwa 3 A, kurze Spitzen erreichen bis zu 5 A
    • Für L1 sollte ein Bauteil mit ausreichend hoher Strombelastbarkeit gewählt werden, um Überhitzung zu vermeiden
  • Für den Proof of Concept wurde ein vorhandener Ethermod‑Adapter verwendet

Netzwerkverhalten und Zugriffsmethode

  • Solange keine Verbindung zu einem Starlink-Satelliten besteht, stellt das Endgerät eine DHCP-IP-Adresse im Netz 192.168.100.0/24 bereit
  • Das Endgerät selbst ist unter 192.168.100.1 erreichbar und betreibt ein einfaches Web-UI sowie einen gRPC-Server für Monitoring und Steuerung
  • Starlink-Debugdaten lassen sich mit grpcurl prüfen
grpcurl -plaintext -d {\"get_status\":{}} 192.168.100.1:9200
SpaceX.API.Device.Device/Handle
  • Nach Verbindung mit dem Starlink-Netzwerk stellt das Ethernet-Interface einen getunnelten DHCP-Dienst bereit
    • Dem Client wird eine IP aus dem Starlink-Pool zugewiesen
    • Üblicherweise werden eine CGNAT-IPv4-Adresse und eine link-globale IPv6-Adresse bereitgestellt
    • Mit dieser Konfiguration wird Internetzugang möglich
  • Der Starlink-DHCP-Server stellt nur eine einzige IP-Adresse bereit
    • Direkt anschließbar ist entweder ein Host oder ein vorgeschalteter Router, der die Verbindung für mehrere Geräte teilt
  • Nachdem eine externe IP bezogen wurde, verliert der Client üblicherweise den Zugriff auf 192.168.100.1
  • Um den Zugriff auf das Endgerät beizubehalten, kann eine statische Route hinzugefügt werden
sudo ip route add 192.168.100.1 dev ethX
  • ethX muss durch den Namen des mit Starlink verbundenen Ethernet-Interfaces ersetzt werden
  • Sobald der Host nach dem Verbinden mit dem Starlink-Netzwerk eine IP-Adresse erhält, ist Internetzugang ohne zusätzliche Konfiguration möglich
  • Konto- und Verbindungsstatus müssen über die gRPC-Ausgabe überwacht werden

gRPC-Statuscodes

  • Die Ausgabe von gRPC get_status enthält Informationen, die bei der Diagnose von Verbindungsproblemen helfen
  • Bei Verbindungsproblemen kann in der gRPC-Ausgabe ein Abschnitt outage erscheinen
"outage": {
  "cause": "NO_SCHEDULE",
  "startTimestampNs": "1815683934050410150",
  "durationNs": "4320001119",
  "didSwitch": true
}
  • Mögliche Werte für outage.cause:
    • BOOTING: Das Endgerät startet gerade und wartet auf Modulinitialisierung und GPS-Fix
    • THERMAL_SHUTDOWN: Das Endgerät wurde zum Schutz der Komponenten wegen Überhitzung abgeschaltet
    • NO_SCHEDULE: Kommunikation mit dem Satelliten ist nicht möglich; mögliche Ursachen sind schwaches Signal, fehlerhafte GPS-Daten oder andere Probleme
    • NO_SATS: Es wurden keine Satelliten am Himmel erkannt
    • OBSTRUCTED: Ein Hindernis im Pfad des Funkstrahls wurde erkannt
    • NO_DOWNLINK: Es können keine Daten vom Satelliten empfangen werden
    • NO_PINGS: Die Verbindung zwischen Endgerät und Satellit bleibt bestehen, aber der Satellit hat die Verbindung zum Bodensegment verloren

Codes für Kontoeinschränkungen

  • Der Starlink-Kontostatus lässt sich im Abschnitt disablementCode prüfen
  • Mögliche disablement codes:
    • UNKNOWN_STATE: Das Endgerät meldet einen undefinierten oder nicht erkannten Zustand
    • OKAY: Das Konto ist aktiv und Internetzugang sollte möglich sein
    • NO_ACTIVE_ACCOUNT: Das Starlink-Konto wurde entfernt oder der Dienst wurde pausiert
    • TOO_FAR_FROM_SERVICE_ADDRESS: Betrieb außerhalb der Region der registrierten Serviceadresse
    • IN_OCEAN: Das Gerät befindet sich in einem Meeresgebiet, das vom aktuellen Serviceplan nicht abgedeckt ist
    • BLOCKED_COUNTRY: Das Gerät befindet sich in einem Land, in dem Starlink-Dienst nicht erlaubt ist
    • DATA_OVERAGE_SANDBOX_POLICY: Das Datenlimit wurde überschritten; für mehr Daten ist ein Wechsel des Serviceplans erforderlich
    • CELL_IS_DISABLED: Die lokale Servicezelle wurde im Starlink-System deaktiviert
    • ROAM_RESTRICTED: Roaming ist für das aktuelle Konto oder den aktuellen Plan nicht erlaubt
    • UNKNOWN_LOCATION: Die Starlink-Satelliten können den Standort des Endgeräts nicht bestimmen
    • ACCOUNT_DISABLED: Das Starlink-Konto wurde gesperrt oder dauerhaft deaktiviert
    • UNSUPPORTED_VERSION: Die Firmware des Endgeräts ist inkompatibel oder veraltet
    • MOVING_TOO_FAST_FOR_POLICY: Das Gerät bewegt sich zu schnell, etwa in einem Fahrzeug oder Flugzeug, und verstößt damit gegen Richtlinienbeschränkungen
    • UNDER_AVIATION_FLYOVER_LIMITS: Das Gerät befindet sich unter einem Luftfahrt-Überfluggebiet, wodurch der Dienst eingeschränkt ist
    • INVALID_COUNTRY: Das Gerät befindet sich in einem von Starlink nicht unterstützten Land
    • UNLICENSED_COUNTRY: Das Gerät befindet sich in einem Land, in dem Starlink keine regulatorische Zulassung erhalten hat
  • disablementCode sollte nach erfolgreicher Satellitenverbindung immer verfügbar sein
  • Das Nutzerendgerät kennt Serviceplan, Land, Region und Geschwindigkeitsbeschränkungen nicht selbst, sondern folgt den vom Starlink-Satelliten empfangenen Befehlen

1 Kommentare

 
GN⁺ 2025-06-16
Meinungen auf Hacker News
  • Der letzte Teil verwirrt mich. Es klingt so, als würden „Deaktivierungscodes“ (Geoblocking, Geschwindigkeitsüberschreitungen usw.) auf dem User Terminal angewendet. Falls ja, hieße das, dass man sie umgehen kann?
    Es hieß, „das User Terminal selbst kennt weder Serviceplan noch Land, Region oder Geschwindigkeitslimit und folgt nur den Befehlen, die es von den Starlink-Satelliten erhält“. Ich hätte eigentlich erwartet, dass das schon in der DHCP-Phase erzwungen wird. Oder vielleicht auch nicht, weil man sich nach Erhalt einer IP zu schnell bewegen könnte. Ich frage mich, ob dieser Artikel im Grunde ein „finde es selbst heraus“-Leitfaden zum Umgehen von Starlink-Richtlinienbeschränkungen ist.

    • Das klingt eher nach Ergebniscodes, die dem Terminal mitgeteilt werden. Zum Beispiel „ACCOUNT_DISABLED – das Starlink-Konto wurde gesperrt oder dauerhaft deaktiviert“ oder „UNLICENSED_COUNTRY – das Terminal befindet sich in einem Land, in dem Starlink keine regulatorische Genehmigung hat“.
      Es erscheint unwahrscheinlich, dass diese Entscheidung vom Terminal statt vom Starlink-Netzwerk getroffen wird.
    • Ich verstehe den Grund, warum der Satellit dem Terminal einen Code sendet, so: Das Terminal selbst weiß sonst nicht einmal, dass es blockiert wurde. So soll der Nutzer sehen können, warum das Internet nicht funktioniert.
    • Ich kenne Starlink nicht besonders gut, aber im Allgemeinen sieht das nach einem Ablauf aus, bei dem die App Fehler- und Diagnosecodes vom Terminal ausliest. Wenn man den eingebauten Router umgeht und das Terminal nur wie ein an einen SBC angeschlossenes Modem verwendet, kann man solche Fehler nicht auf dem Smartphone sehen.
      Deshalb kann man ein Skript schreiben, das Fehlercodes auswertet und entsprechend reagiert. Wenn man zum Beispiel ein Starlink-Terminal an einer Drohne montiert hat, könnte sie automatisch die Position ändern, sobald der Dienst abbricht; wenn ein Hindernis erkannt wird, könnte das unbemannte Fluggerät höher fliegen. Wenn versehentlich ein Geofence überschritten wird und der Dienst abbricht, könnte man das Starlink-Terminal abschalten und ein Ersatz-Kommunikationssystem einschalten. Im Grunde kann man diesen Deaktivierungscode wie einen Sensor verwenden.
    • Wenn tatsächlich herausgefunden worden wäre, wie man bestimmte Deaktivierungscodes täuscht oder umgeht, hätte man das wohl nicht geteilt. Am Ende hängt es davon ab, wie streng Starlink unautorisierte Nutzung prüft und durchsetzt.
      Bei einem US-Unternehmen, das in dieser Größenordnung operiert, scheint alles möglich: von sehr strengen Kontrollen bis hin zu grundlegenden Prüfungen oder Reaktionen nur auf Anfrage. Hier meinte jemand, Starlink funktioniere sogar in Russland, wo es eigentlich nicht funktionieren sollte; vielleicht können einige der an die Ukraine gelieferten Geräte auch in Russland genutzt werden.
    • Diesen Eindruck habe ich überhaupt nicht. Wenn das Terminal keine Informationen zu Serviceplan oder Beschränkungen vorhält, werden diese Informationen auf einer höheren Ebene verwaltet. Aus dem Artikel allein lässt sich nicht ableiten, ob man das Terminal so konfigurieren kann, dass es Beschränkungen ignoriert; aber nur disablementCode zu ignorieren, reicht wahrscheinlich nicht aus.
  • Interessant ist die Entscheidung, statt MACs direkt per RGMII zu verbinden, modifiziertes Board-to-Board-Ethernet zu verwenden.

    • Ethernet wirkt für Prototyping deutlich einfacher. Für Kommunikation über RGMII gibt es kaum fertige Komponenten, die man einfach sofort nutzen kann; Ethernet steckt man zum Testen einfach in einen Laptop.
      Wenn zwei verschiedene Teams jeweils ihren Teil entwickeln, ist es viel einfacher, sich auf Ethernet als Interface zu einigen, Integrationstests nach hinten zu verschieben oder früher auf den Markt zu kommen.
    • RGMII ist nicht für Board-to-Board-Verbindungen ausgelegt. Die Datenrate ist ziemlich hoch, und idealerweise müssen die Laufzeiten aller Signale aufeinander abgestimmt werden.
      Wenn das Design auf zwei Boards aufgeteilt ist, wird es noch heikler, und es dürften auch EMI/EMC-Probleme entstehen. In Evaluation-Kits habe ich so etwas schon gesehen, aber für ein Serienprodukt wirkt es nicht wie eine gute Idee.
    • Insgesamt hat es ziemlich stark den Charakter eines Proof of Concept. Dass digital → analog → analog → digital ineffizient ist, stimmt; abstrakt betrachtet wäre eine MAC-PHY-Verbindung über RGMII wahrscheinlich besser.
      Allerdings habe ich die spontane Vermutung, dass das im Artikel genannte Interface leichter zugänglich war oder dass man dafür weniger tief in die interne Struktur eindringen musste. Man weiß nicht einmal, wo die RGMII-Leitungen liegen, und je nach Design des Starlink Mini könnten sie tiefer vergraben und schwerer zugänglich sein.
    • Ich verstehe den Zweck dieser Arbeit nicht ganz. Der Mini hat bereits eine RJ45-Buchse, man muss das Gerät also nicht hacken, um an den Ethernet-PHY zu kommen. Auf der Einstellungsseite kann man auch den WiFi-Router abschalten.
      Fehlt bei den in der Ukraine bereitgestellten Minis die Unterstützung für die Ethernet-Buchse? Auf den Fotos sieht es so aus, als wäre sie neben der Strombuchse auf dem WiFi-Board weiterhin vorhanden.
    • Dieser Steckverbinder ist viel billiger als einer, der RGMII-Signale ohne starke Reflexionen führen kann. Am Ende kann es günstiger sein, zusätzliches Silizium einzubauen, als einen besseren Steckverbinder zu verwenden; und wenn keine galvanische Trennung nötig ist, braucht man vermutlich auch keine magnetischen Bauteile.
  • Ich verstehe genau, welche Art von Anwendung mit strengen Strombeschränkungen hier im Blick ist, und mir gefällt das.

    • Ich frage mich, welchen konkreten Use Case du meinst.
    • Starlink wird bereits auf dem Nachtbomber Nemesis und auf Magura-Seedrohnen eingesetzt.
    • Also auf einer Drohne montiert?
  • Archivversion: https://archive.ph/UTFTK

  • Welchen SoC verwendet Starlink? Broadcom?

    • MediaTek
  • Sehr gut. Ich wünschte, Starlink würde tatsächlich einen solchen Antenne-plus-Modem-Dienst anbieten und echtes IPv4 statt CGNAT und Ähnlichem bereitstellen. Im deutlich teureren Business-Plan scheint es das wohl zu geben.

    • Man kann über Starlink einen Tunnel aufbauen und eine öffentliche IP bekommen. Wegen der geringeren MTU und des zusätzlichen Hops bis zum Tunnel-Endpunkt ist das nicht 100 % effizient, aber es funktioniert.
    • Bei neuen ISPs ist das der Standardablauf. Ohne guten Plan zur Adressnutzung ist es schwierig, die Genehmigung zum Kauf eines IPv4-Blocks zu bekommen.
      Allen Privatkunden eine öffentliche IP zu geben, gilt inzwischen kaum noch als gute Nutzung des IPv4-Adressraums.
  • Ich frage mich, wie der Autor die Pinbelegung des Ethernet herausgefunden hat. Wirklich beeindruckend.
    Und dass GRPC verwendet wurde, gefällt mir ebenfalls. Das wirkt wie ein Zeichen dafür, dass es kompetente Leute gibt, die nicht hetzen, sondern es richtig machen.