DJOneHub: a macOS tool for the first-generation DJI 4G module

The problem DJOneHub removes: a VM between macOS and the module

The first-generation DJI 4G module was not built with macOS in mind. Its management interface appears only when the module enumerates over USB in a particular combination mode, and the usual workaround has been to hand the device to a Linux virtual machine and drive it from there. DJOneHub is a native alternative. The README describes it as a third-party macOS management tool that talks to the module's existing USB interfaces, so the module can send and receive SMS, manage eSIM profiles, accept AT commands and provide USB 4G internet without a virtual machine.

The audience is narrow and specific. You need the first-generation DJI 4G module, a physical SIM or a compatible physical eUICC card, a USB-C cable that actually carries data, and an Apple Silicon Mac. The README is blunt about the last point: the current preview release ships an Apple Silicon build only, and the Intel version is listed as not yet released. If you are on an Intel Mac, this project is not for you yet, regardless of how well everything else fits.

The README also carries a prominent disclaimer that DJOneHub is an unofficial third-party project with no affiliation, authorization or partnership with DJI, Quectel, carriers or eSIM card vendors. That matters for support expectations: nothing here comes from the hardware vendor.

How DJOneHub talks to the module without touching its firmware

The mechanism is USB mode switching, not firmware modification. The README states that the first-generation DJI 4G module exposes different management or network interfaces to macOS depending on its USB combination mode, and that DJOneHub implements local communication against those existing interfaces with presets for the common SMS and internet modes.

Mode 0 is presented in the UI as SMS mode and covers status reading, SMS, eSIM management and AT commands. Mode 1 is internet mode and exposes a USB network adapter so macOS can route traffic over the SIM. Modes 2 and 3 are labelled experimental, with the README saying their purpose is unconfirmed and that they should not be used day to day.

Switching modes causes the module to re-enumerate its USB interfaces, so the page will briefly show the device as disconnected. The README warns not to unplug the module or switch modes while a write such as an eSIM profile download is in progress. This is the central operational constraint of the tool: the device disappears from the host precisely when you are changing what it does, and the software has to wait for it to come back.

The repository layout matches that architecture. There is a cmd directory for the CLI entry point, internal and pkg directories for the implementation, a scripts directory that holds the packaging script, and a third_party directory. The go.mod file shows the module path as github.com/iniwex5/vohive and replaces several dependencies with local copies under third_party, including euicc-go, uicc-go, quectel-qmi-go, strftime, pkg-errors, x-sys, x-text and multierr. The README explains the lineage: DJOneHub continues development from research into the module and the original VoHive project, and the repository contains parts evolved from that codebase.

Installing DJOneHub and sending a first AT command

Downloads come from the project's Releases page. The README says to pick the ZIP whose filename contains macOS-arm64, and that the matching .sha256 file is not part of the program and not required for installation; it exists so you can confirm the ZIP downloaded completely and matches what the publisher generated. GitHub's auto-generated Source code archives are snapshots for developers, not substitutes for the packaged macOS build.

After downloading, verify the archive from your download directory:

shasum -a 256 DJOneHub-*.zip

Compare the output with the value in the .sha256 file. Then unpack the ZIP completely rather than dragging a single file out of the archive, open Terminal, type cd followed by a space, drag the unpacked DJOneHub folder into the Terminal window, and press Return. Run the installer:

./install

The README notes that macOS may ask for your administrator password during installation and that Terminal will not display dots or asterisks while you type it. The program body lands in /usr/local/libexec/djonehub and the command entry point in /usr/local/bin/djonehub, so the djonehub command works from any directory afterwards.

For the first run, insert the SIM or eUICC card into the module, connect it with a data-capable USB-C cable, and wait for macOS to finish enumerating the device. Then start the program:

djonehub start

The management page opens at http://127.0.0.1:7575. The Terminal window running the program must stay open, and Control+C stops it. If the browser does not open on its own, the README gives djonehub open as the fallback. To reach the AT debugging page, the module should be in SMS mode. The README lists these as example commands:

AT
AT+CSQ
AT+COPS?
AT+CPIN?
AT+CNUM

A word of caution from the same page: AT commands can change network registration, PDP context, USB mode, SMS storage and SIM state. Do not run commands whose effect you do not understand, and do not copy flashing or write commands from unknown sources. If you would rather not install into /usr/local at all, the README documents running ./djonehub start from the fully unpacked release directory instead.

The unsigned preview build and macOS quarantine

The current preview does not carry an Apple Developer ID notarized signature. The README states this plainly and warns that macOS may refuse to verify the developer or block startup on first run. The documented path is System Settings, then Privacy & Security, then choosing Open Anyway near the security prompt and restarting DJOneHub.

If macOS still reports the file as damaged, the README gives a quarantine removal step to run from the unpacked release directory:

xattr -dr com.apple.quarantine ./djonehub ./bin ./lib
./djonehub start

The README attaches a caution to this: only remove the quarantine attribute from files downloaded from the project's trusted Release page and checked against their SHA-256 value. That is sound. Stripping quarantine is a general macOS operation, and applying it to an archive from anywhere else removes one of the few checks you have.

This is a limitation, not a footnote. Every first launch on a new machine costs a trip through Privacy & Security, and anyone who administers Macs at scale will find that friction. The project is at v0.1.0-preview, and the README's own limitations section lists the temporary signature alongside the missing Intel build.

eSIM profile writes are the risky part

The eSIM page manages a compatible eUICC card inserted in the physical SIM slot. It is not for the Mac's built-in eSIM, and if you are using an ordinary physical SIM you can ignore the page entirely. For a compatible card, the README lists reading the EID, firmware, free space and installed profiles; viewing profile name, provider, type and ICCID; downloading a new profile; enabling a profile; renaming it; deleting it; checking card address book compatibility; and saving number details to the module address book linked by ICCID.

The README is direct about the risk. Enabling, downloading, renaming and deleting profiles all modify the physical card, and the module must not be unplugged during a write. Deleting a profile is usually irreversible. Combined with the mode-switching behaviour described earlier, this is where a careless moment costs something real.

Compatibility is the second caveat. The README notes that physical eUICC products following SGP.22 do not necessarily implement every extension identically, and that main features have only been verified on the compatible cards at hand. Other products need their own testing. So even with a card that meets the specification, you are in untested territory until you try it. Treat the first profile operation on an unfamiliar card as an experiment, not a routine action.

Internet mode, traffic counters and the Baiwang network service

Switching to internet mode requires a SIM with usable data. The README says the module typically hands the Mac a LAN address in the 192.168.225.x range over DHCP and handles cellular attach and forwarding itself. On the Mac side, the module appears as a network service; the README records the name observed on the author's machine as Baiwang.

The home page shows current download, current upload, session download, session upload and session total. The total is the sum of session download and upload, and it counts only the current DJOneHub process. Refreshing the page does not reset it, but closing the program does, and the next start begins from zero. The README states that these figures are for observing the current session and are not equivalent to a carrier bill. If you need accounting-grade numbers, this is the wrong instrument.

Proxy configuration is the other practical wrinkle. macOS proxy settings are tied to a network service, so after switching to the USB adapter your proxy may stop working. The README suggests reconfiguring the system proxy for the Baiwang service, or confirming that the proxy software runs in TUN or enhanced mode and listens on the correct port.

There is a cost dimension the README raises in its safety section: before using cellular data, confirm your plan, roaming charges and data caps, and do not switch to internet mode with a foreign SIM or eSIM when the charges are unclear. Mode switching is one click, and the consequences land on your bill.

Where DJOneHub is the wrong tool, and what to use instead

Three cases rule DJOneHub out. You are on an Intel Mac, and the Intel build is not released or hardware-verified. You need other 4G modules supported, and the README says compatibility is not guaranteed because USB identification, interface selection and mode switching are built around the first-generation DJI module; even hardware using similar chips may differ in USB combinations, endpoints and firmware commands. Or you want to run it from an iPhone or iPad, which the README rules out because the program depends on macOS, libusb, a terminal and a local web service, and iOS and iPadOS have different USB permissions and app sandboxing.

The real alternative is the setup DJOneHub was written to replace: a Linux virtual machine with the module passed through over USB, driven by generic modem tooling. The difference is not cosmetic. A VM gives you the full Linux toolchain, including the ModemManager and QMI or MBIM stacks, and it works on Intel Macs. What it costs you is a second operating system to keep patched, USB passthrough to configure, and a host that must be running whenever you want to read a text message. DJOneHub's advantage is that the module appears as a local service on the Mac you already have open, with the management page bound to 127.0.0.1 by default.

That local binding is a genuine design decision worth noting. The README states the program and its pages run on the machine and listen only on 127.0.0.1:7575, and that other devices on the same LAN cannot reach the page directly. For a tool that displays EID, ICCID and SMS content, that default is the right one.

Licence, maintenance and the cost of upgrading

The repository does not declare a standard licence; GitHub reports it as NOASSERTION, and the top-level entries include LICENSE and THIRD_PARTY_NOTICES.md. The README also states that the codebase contains parts evolved from the original VoHive project. Before you redistribute anything or build it into a product, read LICENSE and THIRD_PARTY_NOTICES.md yourself and, if the terms matter commercially, get proper advice. The go.mod file adds its own wrinkle: eight dependencies are replaced with local copies under third_party, including euicc-go, uicc-go, quectel-qmi-go, strftime, pkg-errors, x-sys, x-text and multierr. Vendored replacements like these are convenient for building but they mean you inherit the maintenance of those copies, and their licence terms sit alongside the project's own.

On activity, the last push to the default branch was on 2026-07-28, and the only release listed is v0.1.0-preview from 2026-07-19. That is a young, single-release project. Upgrading is not a background operation: the install places files in /usr/local/libexec/djonehub and /usr/local/bin/djonehub, so a new version means re-running the installer from a fresh, verified archive. Uninstalling is documented and explicit. Stop the program first:

djonehub stop

Then remove the command entry point and program body with sudo rm -f /usr/local/bin/djonehub and sudo rm -rf /usr/local/libexec/djonehub. Logs and local data live at ~/Library/Logs/DJOneHub/djonehub.log and ~/Library/Application Support/DJOneHub, and deleting those directories removes the remaining state. Building from source is possible but aimed at developers: the README requires an Apple Silicon Mac, macOS 13 or newer, Xcode Command Line Tools, Go 1.26.3 or a compatible version, pkg-config, and network access to GitHub Releases to download and verify the official libusb 1.0.30 source. The packaging script is ./scripts/package-macos-arm64.sh, and its output lands in dist/release/.

Editorial conclusion

Adopt DJOneHub if you own a first-generation DJI 4G module, run an Apple Silicon Mac on macOS 13 or newer, and are willing to open an unsigned preview build that writes to real eUICC cards. Do not adopt it if you need Intel support, an Apple-notarized binary, or a tool that manages the Mac's built-in eSIM. Before trusting it with a card, confirm that the module enumerates as USB device 2ca3:4006, that the ZIP matches its published .sha256 file, and that the eUICC in the slot is one you can afford to lose if a profile write fails.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. ZenGeekLabs/DJOneHub on GitHub