# 让大疆 4G 模块经 Linux 接入 Mac

> 这个社区项目借助 UTM Linux 虚拟机和 VoHive 重新利用大疆一代 4G 模块；它是附带脚本与归档的指南，不是 macOS 原生驱动，而且 Apple Silicon 的当前部署链路并不完整。

_Source: First-party repository for project contents; hardware outcomes are maintainer-reported and were not independently reproduced · 2026-07-26 · 8 min read · Verified against primary sources_

Canonical: https://iyu.app/zh/e/dji-4g-vohive-mac

## 60 秒版本

UTM Linux 虚拟机把大疆 EG25-G 永久改识别为移远 EC25，三个脚本再让它在 VoHive 的 QMI 与 macOS 的 ECM 数据模式间切换。

**要点**

- 它是指南、脚本和归档的组合，不是 macOS 原生驱动。
- Intel 有 x86_64 内置备份；v1.5.5 零资产期间，Apple Silicon 没有自备 arm64 二进制就会受阻。
- 模块同一时刻只能归虚拟机或 Mac，每次重启切换会中断约 10-30 秒。
- 必须修改默认凭据、限制 sudo、固定 SSH 主机，并独立评估不透明的内置二进制。

**结论.** 这是一座技术逻辑成立的 Linux 桥梁，但只适合愿意承担硬件修改、二进制来源和交接限制的用户。

## 全文

> **!** 先确认范围：这是社区指南，仓库另含三个 shell 脚本和若干归档，并非 macOS 原生驱动。硬件表现来自项目自述，本文未做独立复现。


### 架构 — Linux 才是兼容层

项目通过在 macOS 与大疆一代 4G 模块之间加入 **UTM 和 Linux 虚拟机**，解决 USB 身份与操作系统支持不匹配的问题。UTM 把物理 USB 设备直通给 Linux，由 Linux 的串口和 QMI 能力配置模块并运行 VoHive。macOS 仍是宿主机和浏览器控制端；VoHive 本身没有变成 Mac 应用。

- **2ca3:4006** — 改写前的大疆 USB 身份
- **2c7c:0125** — 改写后的移远 EC25 身份
- **3** — 仓库附带的模式与状态脚本

关键操作针对项目所称的内置 **Quectel EG25-G**。Linux 先暴露 AT 串口，再用 `AT+QCFG` 把新 VID/PID 写入模块的持久配置。重启后，模块枚举为 `2c7c:0125`，Linux 与 VoHive 因而能将其当作 EC25 类设备。这是设备侧的长期修改，不是 UTM 提供的临时别名。

> **i** 永久改写 USB 身份会影响模块以后连接的每一台电脑。在修改不能承受损失的硬件前，应先规划恢复原身份的方法。


### 决策门槛 — Mac 架构支持与二进制供应是两回事

- **路径:** 2026-07-26 的虚拟机与资产状态
- **Apple Silicon:** UTM 可原生运行 arm64 Linux，但除非用户自备 arm64 VoHive 二进制或上游恢复资产，否则部署受阻。
- **Intel Mac:** UTM 可原生运行 x86_64 Linux，且仓库提供 x86_64 离线备份。
- **上游 v1.5.5:** 安装器预期下载对应架构文件，但发布 API 当前列出零个资产。

README 在虚拟机搭建层面确实覆盖 Apple Silicon 与 Intel，但这不代表两条部署路径今天都可用。内置 `vohive-backup.tar.gz` 只有 x86_64 可执行文件；与此同时，上游 VoHive v1.5.5 当前没有可下载资产。Apple Silicon 用户因此要自行取得并审查 arm64 二进制，或等待上游恢复发布文件。


### 两种角色 — 模块会移动，但不会被共享

- **用途:** 模式、归属与结果
- **VoHive:** QMI（`usbnet=0`），归 Linux 虚拟机；VoHive 可使用控制与数据接口。
- **Mac 上网:** ECM（`usbnet=1`），归 macOS；模块表现为蜂窝网络接口。

脚本实现的是不对称交接。`eg25-to-mac.sh` 停止 VoHive，并让模块进入 ECM；模块重启后 UTM 直通断开，设备回到 macOS。`eg25-to-vohive.sh` 必须从 **本地 macOS 图形会话**启动，因为 `utmctl` 要在那里与 UTM.app 通信。它先把 ECM 设备接入 Linux，改回 QMI，等待再次重启，再连接一次并启动 VoHive。`eg25-status.sh` 用于检查归属与接口。

- **10-30 秒** — 项目报告的单次模式切换中断
- **1 个归属方** — 同一时刻只能是虚拟机或 macOS
- **2 次接入** — Mac 切回 VoHive 的脚本流程

> **!** 切换并非无缝：模块会重启，服务会中断；ECM 模式还可能消耗收费的 SIM 流量，包括昂贵的漫游流量。


### 风险审查 — 自动化捷径也是信任决策

- 立即替换 VoHive 默认的 `admin/admin` 凭据。
- 用按命令限定的 sudoers 规则替代 README 建议的 `NOPASSWD: ALL`。
- 用受控的 `known_hosts` 条目替换脚本中的 `StrictHostKeyChecking=no`。
- 在独立评估前，把内置的预编译 VoHive 二进制视为不透明文件。
- 开启 macOS ECM 数据模式前，确认 SIM 套餐和漫游资费。

本地观察到的仓库文件 SHA-256 为：`vohive-backup.tar.gz` 是 `48dfd43fb909d33898a494c1bfd48b5caa6085a957361cd5b736f47d65277440`，`vohive-release-1.5.5.zip` 是 `409a8864a6310efcafbba3c7f33d10ece832115a166a87e5355803e3caf218f4`。记录这些值可以发现相同文件后来是否变化，却不能证明可执行文件由谁构建、是否对应源码或是否安全。

> **i** 时效性快照：2026-07-26，项目仓库 API 显示 751 个 star、316 个 fork、8 个未关闭 issue。热度不等于安全审计，而且这些数字会变化。


### 来源 — “已验证”在这里有严格边界

本文把来源标记为已验证，是因为仓库足以证明 **项目包含什么、声称什么**：一份指南、三个脚本、两个归档及其工作流。这不等于独立验证模块兼容性和运行效果。许可也要分层看：README 称文档采用 CC-BY-4.0，GitHub 仓库 API 的 license 字段却为空；附带的上游脚本与二进制可能受不同条款约束。


### 结论 — 选择约束，而不只是功能

这个项目最可信的价值，是清楚展示如何在 Mac 上借 Linux 转接专用 USB 硬件。Intel 用户当前有内置执行路径，但仍需审查二进制；Apple Silicon 用户具备虚拟机架构，却没有完整的内置 arm64 路径。无论哪种平台，只有在能接受永久身份改写、单一归属、短时中断和自行负责安全时，才适合继续。


## Primary sources

- [dji-4g-vohive-mac repository](https://github.com/wlzh/dji-4g-vohive-mac)
- [VoHive v1.5.5 release page](https://github.com/iniwex5/vohive-release/releases/tag/v1.5.5)
- [VoHive v1.5.5 release API](https://api.github.com/repos/iniwex5/vohive-release/releases/tags/v1.5.5)
- [Project repository API metadata](https://api.github.com/repos/wlzh/dji-4g-vohive-mac)

---
_Published by iyu (https://iyu.app) — the day's AI news, checked against primary sources and rewritten in plain language. Free to quote with attribution and a link to the canonical URL._