DJI 4GモジュールをLinux経由でMacへ
このコミュニティープロジェクトは、UTM上のLinux VMとVoHiveを介して初代DJI 4Gモジュールを再利用する。macOSネイティブドライバーではなく、ガイド、スクリプト、同梱物の組み合わせであり、Apple Silicon向けの現行導入経路は未完成だ。
60秒でわかる
UTMのLinux VMでDJI EG25-GをQuectel EC25として永続的に再識別し、3本のスクリプトでVoHiveのQMIとmacOSのECMデータを切り替える。
要点
- macOSネイティブドライバーではなく、ガイド、スクリプト、アーカイブの組み合わせだ。
- Intelにはx86_64バックアップがあるが、v1.5.5のアセットがゼロの間、Apple Siliconはarm64バイナリーなしでは進めない。
- モデムはVMかMacの一方だけに属し、再起動を伴う切り替えで約10秒から30秒中断する。
- 既定資格情報の変更、sudoの限定、SSHホスト固定、不透明なバイナリーの独立評価が必要だ。
結論. 技術的には筋の通ったLinuxブリッジだが、ハードウェア変更、バイナリー来歴、受け渡し制約を自分で引き受けられる利用者向けだ。
アーキテクチャー互換レイヤーはLinux
このプロジェクトは、macOSと初代DJI 4Gモジュールの間に UTMとLinux VM を置き、USB IDとOS対応の不一致を解決する。UTMが物理USBデバイスをLinuxへ渡し、Linuxのシリアル機能とQMI機能でモデムを設定し、VoHiveを稼働させる。macOSはホスト兼ブラウザー操作端末のままで、VoHive自体がMacアプリになるわけではない。
重要な操作は、プロジェクトが内部部品として示す Quectel EG25-G を対象とする。LinuxでATシリアルポートを公開し、`AT+QCFG`で新しいVID/PIDをモデムの永続設定へ書き込む。再起動すると`2c7c:0125`として列挙され、LinuxとVoHiveからEC25系モデムとして扱える。UTMによる一時的な別名ではなく、デバイス側に残る変更だ。
判断条件MacのCPU対応とバイナリー供給は別問題
| 経路 | 2026-07-26時点のVMとアセット状況 |
|---|---|
| Apple Silicon | UTMでarm64 Linuxは動くが、arm64版VoHiveバイナリーを用意するか上流アセットが復旧するまで導入できない。 |
| Intel Mac | UTMでx86_64 Linuxが動き、リポジトリーにはx86_64オフラインバックアップがある。 |
| 上流v1.5.5 | インストーラーはアーキテクチャー別ダウンロードを想定するが、リリースAPIのアセットは現在ゼロ。 |
READMEのVM構築はApple SiliconとIntelの両方を扱うが、現時点で両方が導入可能という意味ではない。同梱の`vohive-backup.tar.gz`にはx86_64実行ファイルしかなく、上流VoHive v1.5.5には現在ダウンロード可能なアセットがない。Apple Silicon利用者はarm64バイナリーを別途入手して検証するか、上流の復旧を待つ必要がある。
2つの役割モデムは移動するが共有されない
| 役割 | モード、所有者、結果 |
|---|---|
| VoHive | QMI（`usbnet=0`）、Linux VM所有。VoHiveが制御・データインターフェースを利用できる。 |
| Macデータ | ECM（`usbnet=1`）、macOS所有。セルラーネットワークインターフェースとして表示される。 |
スクリプトによる受け渡しは非対称だ。`eg25-to-mac.sh`はVoHiveを停止してECMへ変更し、再起動でUTMパススルーが外れるとデバイスはmacOSへ戻る。`eg25-to-vohive.sh`は、`utmctl`がUTM.appと通信できる ローカルmacOSグラフィカルセッション から実行しなければならない。ECMデバイスをLinuxへ接続し、QMIへ戻して再起動を待ち、もう一度接続してVoHiveを開始する。`eg25-status.sh`は所有者とインターフェースを調べる。
リスク評価自動化の近道は信頼判断でもある
- VoHiveの既定資格情報`admin/admin`を直ちに変更する。
- READMEが示す`NOPASSWD: ALL`ではなく、コマンド限定のsudoers規則を使う。
- スクリプトの`StrictHostKeyChecking=no`を管理された`known_hosts`へ置き換える。
- 独立評価までは、同梱プリコンパイル済みVoHiveバイナリーを不透明なものとして扱う。
- macOSのECMデータモードを有効にする前にSIM料金とローミング条件を確認する。
観測したリポジトリーファイルのSHA-256は、`vohive-backup.tar.gz`が`48dfd43fb909d33898a494c1bfd48b5caa6085a957361cd5b736f47d65277440`、`vohive-release-1.5.5.zip`が`409a8864a6310efcafbba3c7f33d10ece832115a166a87e5355803e3caf218f4`だった。記録値は後日のファイル変更を検出できるが、誰がビルドしたか、ソースと一致するか、安全かは証明できない。
来歴ここでの「検証済み」には限界がある
この記事でソースを検証済みとするのは、リポジトリーが プロジェクトの内容と主張、つまりガイド、3本のスクリプト、2つのアーカイブとワークフローについての一次資料だからだ。モデム互換性や実際の結果を独立検証したという意味ではない。ライセンスも分離が必要で、READMEは文書をCC-BY-4.0としている一方、GitHub APIのlicenseフィールドはnullで、同梱上流スクリプトとバイナリーには別条件があり得る。
結論機能だけでなく制約を選ぶ
このプロジェクトの明確な価値は、Mac上で特殊なUSBハードウェアをLinux経由で扱う設計図にある。Intelには現在同梱の実行経路があるが、バイナリー評価は必要だ。Apple SiliconにはVM構成がある一方、完全なarm64供給経路がない。永続ID変更、排他的所有、短い停止、自主管理のセキュリティーを受け入れられる場合にだけ進むべきだ。