- 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
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.
Es erscheint unwahrscheinlich, dass diese Entscheidung vom Terminal statt vom Starlink-Netzwerk getroffen wird.
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.
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.
disablementCodezu ignorieren, reicht wahrscheinlich nicht aus.Interessant ist die Entscheidung, statt MACs direkt per RGMII zu verbinden, modifiziertes Board-to-Board-Ethernet zu verwenden.
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.
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.
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.
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.
Ich verstehe genau, welche Art von Anwendung mit strengen Strombeschränkungen hier im Blick ist, und mir gefällt das.
Archivversion: https://archive.ph/UTFTK
Welchen SoC verwendet Starlink? Broadcom?
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.
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.