A DJI 4G Module on Mac, Through Linux
This community project reroutes a first-generation DJI modem through a UTM Linux VM and VoHive; it is a guide with scripts and bundled artifacts, not a native macOS driver, and its Apple Silicon deployment path is currently incomplete.
The 60-second version
A UTM Linux VM permanently re-identifies a DJI EG25-G modem as a Quectel EC25, then three scripts switch it between VoHive QMI service and macOS ECM data.
Key points
- It is a guide plus scripts and archives, not a native macOS driver.
- Intel has a bundled x86_64 fallback; Apple Silicon is blocked without an arm64 VoHive binary while v1.5.5 has no assets.
- The modem belongs to either the VM or Mac, and each rebooting switch interrupts service for about 10-30 seconds.
- Change default credentials, scope sudo, pin SSH hosts, and independently assess the opaque bundled binary.
Verdict. A technically coherent Linux bridge with real operational value, but only for users willing to own its hardware modification, binary provenance and handoff constraints.
ArchitectureLinux is the compatibility layer
The project solves a USB and operating-system mismatch by putting UTM and a Linux VM between macOS and the first-generation DJI 4G module. UTM passes the physical USB device into Linux, where Linux serial and QMI facilities can configure the modem and host VoHive. macOS remains the host and browser-facing control point; VoHive itself does not become a Mac application.
The key operation targets the reported Quectel EG25-G inside the DJI module. Linux first exposes its AT serial port, then `AT+QCFG` writes a new VID/PID into the modem's persistent configuration. After reboot, it enumerates as `2c7c:0125`, which lets Linux and VoHive treat it as an EC25-class modem. This is a lasting device-side modification, not a temporary alias supplied by UTM.
Decision gateMac architecture and binary availability are separate questions
| Path | VM and artifact status on 2026-07-26 |
|---|---|
| Apple Silicon | arm64 Linux via UTM works, but deployment is blocked unless the user supplies an arm64 VoHive binary or upstream restores assets. |
| Intel Mac | x86_64 Linux via UTM works, and the repository bundles an x86_64 offline backup. |
| Upstream v1.5.5 | The installer expects architecture-specific downloads, but the release API currently lists zero assets. |
The README correctly describes VM setup for both Apple Silicon and Intel, but that does not make both deployment paths operational today. The bundled `vohive-backup.tar.gz` contains an x86_64 executable only. Meanwhile, the upstream VoHive v1.5.5 release currently exposes no downloadable assets. An Apple Silicon user therefore needs to obtain and vet an arm64 binary independently, or wait for upstream assets to return.
Two rolesThe modem moves; it is never shared
| Role | Mode, owner and result |
|---|---|
| VoHive | QMI (`usbnet=0`), owned by the Linux VM; VoHive can use modem control and data interfaces. |
| Mac data | ECM (`usbnet=1`), owned by macOS; the modem appears as a cellular network interface. |
The scripts encode an asymmetric handoff. `eg25-to-mac.sh` stops VoHive and asks the modem to enter ECM mode; its reboot causes UTM passthrough to drop, returning the device to macOS. `eg25-to-vohive.sh` must be launched from a local macOS GUI session, because `utmctl` communicates with UTM.app there. It attaches the ECM device to Linux, changes it back to QMI, waits through another reboot, attaches it again, and starts VoHive. `eg25-status.sh` inspects ownership and interfaces.
Risk reviewAutomation shortcuts become trust decisions
- Replace VoHive's default `admin/admin` credentials immediately.
- Prefer command-scoped sudoers entries over the README's suggested `NOPASSWD: ALL`.
- Replace `StrictHostKeyChecking=no` in the scripts with a managed `known_hosts` entry.
- Treat the bundled precompiled VoHive binary as opaque until independently assessed.
- Confirm SIM plan and roaming charges before enabling macOS ECM data mode.
Observed repository-file SHA-256 values are `48dfd43fb909d33898a494c1bfd48b5caa6085a957361cd5b736f47d65277440` for `vohive-backup.tar.gz` and `409a8864a6310efcafbba3c7f33d10ece832115a166a87e5355803e3caf218f4` for `vohive-release-1.5.5.zip`. Recording them can reveal later changes to those exact files. It cannot prove who built the executable, whether its source corresponds to the binary, or whether it is safe.
ProvenanceVerification has a narrow meaning here
This article marks the source verified because the repository is authoritative for what the project contains and claims: a guide, three scripts, two archives and its stated workflow. That does not independently validate modem compatibility or operating outcomes. Licensing also needs separation: the README states CC-BY-4.0 for documentation, GitHub's repository API returns a null license field, and bundled upstream scripts and binaries may be governed by different terms.
Bottom lineChoose the constraints, not just the feature list
The project is most credible as a clear blueprint for routing specialized USB hardware through Linux on a Mac. Intel users have a currently bundled execution path, subject to binary review. Apple Silicon users have the VM architecture but not a complete supplied arm64 path. In either case, proceed only if a permanent identity rewrite, exclusive ownership, brief outages and a self-managed security posture are acceptable.