The LTE Modem page (/ltemodem) can carry IP data over three paths, chosen with
the Data path mode selector. AT status polling (signal, registration,
operator, IP) is the same in every mode; only the data call differs.
ModemManager is still never used in any mode. It auto-probes serial ports and can seize the flight-controller UART, so QMI uses libqmi and PPP uses pppd directly.
flightController.jsstill hard-errors if ModemManager is installed.
| Mode | Interface | How the data call is made | Packages |
|---|---|---|---|
| RNDIS (default) | usb0 |
AT$QCRMCALL=1,1 over the AT port |
none (built-in) |
| QMI | wwan0 |
qmicli --wds-start-network + DHCP (udhcpc) |
libqmi-utils |
| PPP | ppp0 |
pppd dials *99# via a chat script |
ppp |
Set Data network interface to match the mode (usb0 / wwan0 / ppp0) so
usage accounting and the connection test watch the right interface.
The Status section has Connect (uses the configured mode) and Disconnect:
- RNDIS:
AT$QCRMCALL=1,1/AT$QCRMCALL=0,1 - QMI:
qmicli --device-open-proxy --wds-start-network(handle/CID captured) /--wds-stop-network. The--device-open-proxyflag routes everyqmiclicall through the qmi-proxy so it shares thecdc-wdmdevice with the kernel (and other calls) — without it a second opener gets a CID-allocation timeout, and the kept--client-no-release-cidonly survives between the start and stop invocations when both go through the proxy. - PPP:
pppd … connect "chat … ATD*99#"/poff
Auto-reconnect (registered but no IP) uses the same mode-aware path.
PPP dials on PPP port (or the AT port if blank). The server refuses to dial
the flight-controller's serial port (checked against flightcontroller.activeDevice),
so a PPP data call can never disrupt the FC link.
| Endpoint | Method | Notes |
|---|---|---|
/api/ltemodemmodify |
POST | now also takes dataPathMode (rndis/qmi/ppp), qmiDevice, pppPort, pppBaud |
/api/ltemodemconnect |
POST | bring the data call up using the configured mode |
/api/ltemodemdisconnect |
POST | bring the data call down |
server/ltemodem.js routes every QMI/PPP shell-out through one _exec seam, so
the wrappers are unit-tested via fake binaries with no hardware. The real
qmicli/udhcpc/pppd round-trips are verified on-device.
/dev/cdc-wdm0 (QMI) is root-only and pppd is setuid-root/dip-group, so the
QMI/PPP helpers run their commands with sudo (sudo qmicli, sudo udhcpc,
sudo ip link set, sudo pppd, sudo poff). The .deb installs a sudoers
drop-in (/etc/sudoers.d/allow-vpn-control) granting the rpanion service user
passwordless access to exactly those commands — nothing else. RNDIS needs no
sudo (the service user opens the AT serial port directly via the dialout group).
This is a modem USB-composition setting, not a hardware limitation. SIM7600
(and similar) modules can present their data interface as either QMI
(qmi_wwan → cdc-wdm0 + wwan0) or RNDIS/ECM (usb0), selected by the
USB PID. A modem on PID 1e0e:9001 enumerates as QMI (no usb0). QMI is
generally the more robust choice, so prefer it unless you have a reason not to.
You can switch composition from the LTE Modem page (USB composition → choose
QMI/RNDIS → Switch USB mode & reboot modem), which sends
AT+CUSBPIDSWITCH=<pid>,1,1 (QMI 9001, RNDIS 9011) and reboots the modem
(~30 s; interfaces re-enumerate). Afterwards set the Data path mode to match,
re-scan and reconnect.
- QMI:
libqmi-utils(qmicli) andudhcpcare.debdependencies. The.debinstalls a udev rule (77-rpanion-qmi-rawip.rules) that sets raw-IP (qmi/raw_ip=Y) automatically when theqmi_wwaninterface appears, and a NetworkManager drop-in that markswwan0unmanaged (so NM doesn't fight the manual data call). No manual sysfs step needed. - PPP:
ppp(pppd/poff) — already a dependency. - A SIM must be inserted and the carrier APN set on the LTE Modem page; then
pick QMI mode +
wwan0and hit Connect.