- Starlink Mini 1は統合Wi-Fiルーターを取り外してEthernet専用端末として運用でき、カスタムネットワーク構成や組み込み設置での選択肢が広がる
- 改造対象は2025年6月14日時点でStarlink Mini 1に限定され、Mini 2のような後続ハードウェアでは手順が適合しない可能性がある
- 分解の過程でStarlink PCBの金属板はヒートシンクとEMIシールドの役割を持つため、取り外すとスロットリングや電磁波干渉のリスクが高まる
- 本体とルーターは1Gbps Ethernetリンクと12VDC電源バスで接続されており、ユーザー設計では短い内部直結とは異なりEthernetトランスが必要になる
- ルーター取り外し後、端末は192.168.100.0/24でDHCPとgRPC状態インターフェースを提供するが、衛星接続後に複数の機器を使うには上位ルーターが必要になる
改造範囲と分解時の注意点
- Starlink Miniは統合Wi-Fiルーターを含むオールインワン端末だが、内部ルーターボードを物理的に取り外すことでEthernet専用として運用できる
- 適用対象は2025年6月14日時点でStarlink Mini 1であり、今後Mini 2のようなモデルでハードウェア変更が行われると手順が無効になる可能性がある
- 分解には忍耐と精密さが必要で、金属スパッジャーとプラスチック製のこじ開け工具が推奨される
- ルーターPCBを取り外す際には、薄くて柔軟なナイフまたは細い金属ワイヤーが必要になる
- ルーターPCBの取り外し後は分解を止めてもよく、Starlink PCBの金属板の取り外しは強く推奨されない
- 金属板はヒートシンクとEMIシールドの両方の役割を果たす
- Starlink CPUは発熱が大きく、冷却が不十分だとCPUまたはアンテナアレイがスロットリングする可能性がある
- 金属板の縁は導電性接着剤で固定されており電磁波シールドを助けるため、取り外すと放射の増加や周辺電子機器への干渉が起こりうる
PCBコネクタとピン構成
- Starlink Mini PCBのコネクタ種別は正確には分かっておらず、カスタム発注品の可能性がある
- コネクタのピッチは2mmなので、標準の2mm headerが適合する可能性がある
- コネクタは導電性接着剤と広いグランド領域で固定されており、ルーターPCB側のコネクタ上にはシールドがある
- 本体とルーターの間には1Gbps Ethernetリンクが使われている
- 内部接続はEthernetトランスなしで、わずかなデカップリングを含むPHY-to-PHYの直結になっている
- 短距離では許容されるが、ユーザー設計の設置ではEthernetトランスが必須となる
- 基本の電源バスは12VDC
- ピン11、14、16、17、18は現在の改造では使用されず、主にStarlink-ルーター間の監視用途となっている
- 安定した電源供給のため、すべての12VDCとGNDラインを使うことが推奨される
直接Ethernet接続の設計
- 直接Ethernet接続の例では、Starlink Mini 1 PCBコネクタに必要なEthernet絶縁と最小限の電源フィルタリングを提供する回路を使用する
- U1コネクタ周辺にはガードグランドを設けることが推奨される
- 最適な設計には導電性接着剤とシールドが含まれる
- コネクタとEthernetトランスの間の配線は可能な限り短く保つべき
- 12V基準での通常動作電流は約3Aで、短時間のスパイクでは5Aまで上がる
- L1は過熱を避けられるよう適切な定格電流の部品を選ぶ必要がある
- 概念実証には既存のEthermodアダプターが使われている
ネットワーク動作とアクセス方法
- Starlink衛星に接続していない状態では、端末は192.168.100.0/24ネットワークのDHCP IPアドレスを提供する
- 端末自体には192.168.100.1でアクセスでき、簡易Web UIとgRPC監視/制御サーバーが動作している
- Starlinkのデバッグデータはgrpcurlで確認できる
grpcurl -plaintext -d {\"get_status\":{}} 192.168.100.1:9200
SpaceX.API.Device.Device/Handle
- Starlinkネットワークに接続された後、EthernetインターフェースはトンネリングされたDHCPサービスを提供する
- クライアントにはStarlinkプールのIPが割り当てられる
- 一般的にはCGNAT IPv4アドレスとlink-global IPv6アドレスが提供される
- この構成でインターネットアクセスが可能になる
- Starlink DHCPサーバーは単一のIPアドレスしか提供しない
- 直接接続できる対象はホスト1台、または複数機器へ接続共有を行う上位ルーター1台となる
- 外部IPを受け取ると、クライアントは自然に192.168.100.1へのアクセスを失う
- 端末へのアクセスを維持するには静的ルートを追加できる
sudo ip route add 192.168.100.1 dev ethX
ethXはStarlinkに接続されたEthernetインターフェース名に置き換える必要がある- ホストがStarlinkネットワーク接続後にIPアドレスを取得すれば、追加設定なしでインターネットアクセスが可能になる
- アカウント状態と接続状態はgRPC出力で監視する必要がある
gRPCステータスコード
- gRPC get_status出力には、接続問題の診断に役立つ情報が含まれている
- 接続問題がある場合、gRPC出力に
outageセクションが現れることがある
"outage": {
"cause": "NO_SCHEDULE",
"startTimestampNs": "1815683934050410150",
"durationNs": "4320001119",
"didSwitch": true
}
outage.causeの取りうる値:
- BOOTING: 端末が起動中で、モジュール初期化とGPS固定を待っている状態
- THERMAL_SHUTDOWN: 過熱により部品保護のため端末が停止した状態
- NO_SCHEDULE: 衛星と通信できない状態で、弱い信号、誤ったGPSデータ、その他の問題が原因の可能性がある
- NO_SATS: 空で衛星を検出できていない状態
- OBSTRUCTED: 無線ビーム経路に障害物が検出された状態
- NO_DOWNLINK: 衛星からデータを受信できない状態
- NO_PINGS: 端末と衛星の接続は維持されているが、衛星が地上セグメントとの接続を失っている状態
アカウント制限コード
- Starlinkアカウント状態は
disablementCodeセクションで確認できる
- 取りうるdisablement code:
- UNKNOWN_STATE: 端末が未定義または認識されない状態を報告している
- OKAY: アカウントは有効で、インターネットアクセスが可能なはずの状態
- NO_ACTIVE_ACCOUNT: Starlinkアカウントが削除された、またはサービスが一時停止されている
- TOO_FAR_FROM_SERVICE_ADDRESS: 登録されたサービス住所エリア外で動作している
- IN_OCEAN: 現在のサービスプランがカバーしていない海域にいる
- BLOCKED_COUNTRY: Starlinkサービスが許可されていない国にいる
- DATA_OVERAGE_SANDBOX_POLICY: データ上限を超過しており、さらに利用するにはサービスプラン変更が必要
- CELL_IS_DISABLED: Starlinkシステムでローカルサービスセルが無効化されている
- ROAM_RESTRICTED: 現在のアカウントまたはプランではローミングが許可されていない
- UNKNOWN_LOCATION: Starlink衛星が端末の位置を確認できない
- ACCOUNT_DISABLED: Starlinkアカウントが停止または恒久的に無効化されている
- UNSUPPORTED_VERSION: 端末ファームウェアに互換性がない、または古い
- MOVING_TOO_FAST_FOR_POLICY: 車両や航空機のように速く移動しすぎてポリシー制限に違反している
- UNDER_AVIATION_FLYOVER_LIMITS: 航空機の飛行区域下にあり、サービスが制限されている
- INVALID_COUNTRY: Starlinkがサポートしていない国にいる
- UNLICENSED_COUNTRY: Starlinkが規制承認を得ていない国にいる
disablementCodeは衛星接続が成功した後であれば常に利用可能なはず- ユーザー端末はサービスプラン、国、地域、速度制限を自前では認識せず、Starlink衛星から受け取った命令に従う
1件のコメント
Hacker News のコメント
最後の部分が紛らわしい。「無効化コード」（地域ブロック、速度超過など）がユーザー端末で適用される、というニュアンスに見えるが、だとすると回避できるということなのかと思ってしまう。
「ユーザー端末自体はサービスプラン、国、地域、速度制限を知らず、Starlink 衛星から受け取った命令に従うだけ」と書かれていたが、当然 DHCP の段階で強制されるものだと思っていた。あるいは、IP を受け取った後にあまりに速く移動できてしまうので、そうではないのかもしれない。この記事が実質的に Starlink のポリシー制限を回避するための「察してくれ」式のガイドなのか気になる。
その判定を Starlink ネットワークではなく端末が担う構造である可能性は低そうに見える。
だからエラーコードを確認し、それに応じて対応するスクリプトを作れる。たとえば Starlink 端末をドローンに載せているなら、サービスが切れたときに自動で位置を変えられるし、障害物が検知されれば無人機をもっと高く飛ばすこともできる。ジオフェンスを誤って越えてサービスが切れたら、Starlink 端末をオフにして予備の通信システムをオンにすることもできる。実質的にこの無効化コードをセンサーのように使える。
この規模で運営されている米国企業なら、非常に厳格なレベルから、基本的な検査や要請時の対応程度まで、どこでもあり得そうだ。ここで誰かが、Starlink は本来使えないはずのロシアでも使えると言っていたが、ウクライナに渡された一部の機器がロシアでも使えてしまうのかもしれない。
disablementCodeを無視するだけでは十分でない可能性が高い。MAC 同士で RGMII を直接つなぐのではなく、変調されたボード間 Ethernetを使っている選択が興味深い。
別々の 2 チームがそれぞれ作っているなら、インターフェースを Ethernet にしておく方がはるかに簡単で、統合テストを後回しにしたり、より早くリリースしたりできる。
ボードが 2 枚に分かれるとさらに難しくなり、EMI/EMC の問題も出そうだ。評価キットではそういうやり方を見たことがあるが、量産品には良い考えには見えない。
ただ、記事に出ているインターフェースの方がアクセスしやすかった、あるいは内部構造をそこまで深く掘らずに済んだのではないか、という場当たり的な推測はできる。RGMII のラインがどこにあるのかも分からないし、Starlink Mini 自体の設計によってはもっと深いところに埋まっていてアクセスしにくかったのかもしれない。
ウクライナで提供されている Mini では Ethernet ジャックのサポートが省かれているのだろうか？写真を見る限り、電源ジャックの横の WiFi ボードに今もあるように見える。
電力制約のあるどんな用途を想定しているのか正確に分かるし、気に入った。
アーカイブ版: https://archive.ph/UTFTK
Starlink はどんな SoC を使っているのか？Broadcom か？
とても良かった。Starlink が実際にこういう形のアンテナ＋モデムサービスと、CGNAT のようなものではない本物の IPv4 を提供してくれるといいのだが。かなり高いビジネスプランにはあるようではある。
すべての家庭向け顧客にグローバル IP を与える方式は、もはや IPv4 空間のうまい使い方とは見なしにくい。
著者が Ethernet のピン配列をどうやって突き止めたのか気になる。本当にすごい。
それに GRPC を使っているのも良い。急がずにきちんとやる有能な人たちがいるというサインのように見える。