wwand: add cellular connection manager

[ddimension]

Adds wwand, an event-driven cellular connection manager written in ucode: native QMI, MBIM and NCM/AT control (no uqmi/qmicli/libqmi/glib), direct netifd integration (the daemon owns the context lifecycle — no per-interface monitor process; transient loss renews in place so IPv6-PD/VRF survive), multi-modem + multi-PDP-context via QMAP multiplexing, SIM/eSIM management (SGP.22 via lpac), SMS (send + receive), telemetry, a recovery ladder, board profiles and zero-config autosetup. A wwandctl CLI and a LuCI app (openwrt/luci#8917) sit on top.

Upstream repo: https://github.com/ddimension/wwand (GPL-2.0-only, 2856 host-side checks run without hardware). Current release: v1.4.7 — the release this Makefile pins.

One source package, six binary packages:

• wwand — backend-neutral base (daemon, codec, netifd proto shim, SIM/APDU layer, wwandctl CLI). It also ships the small native C transport module wwand_io.so (message-oriented cdc-wdm/tty I/O + rmnet netlink helper) — wwand-private and always version-locked to the ucode side, so it lives inside the base package (PROVIDES ucode-mod-wwand-io for older configs).
• wwand-qmi / wwand-mbim / wwand-ncm — per-protocol control backends; install only what the modems need (wwand-qmi pulls in wwand; a typical QMI router needs just that).
• wwand-mhi — PCIe/MHI transport bundle (MHI bus/PCI/control/data kmods + the kernel-wwan-subsystem hotplug) for modems whose control port appears under /sys/class/wwan instead of usbmisc. Backend-neutral: pair with wwand-qmi or wwand-mbim.
• wwand-esim — optional SGP.22 profile management + SM-DP+ download (depends on lpac >= 2.3.0).

Packaging. The ucode tree is flat; each package installs an explicit per-file list — no glob-then-rm, so every module is owned by exactly one package and a new backend file can never silently ship in the base too. The ucode tree ships as source. Bytecode precompilation is available via CONFIG_WWAND_UCODE_PRECOMPILE but stays opt-in: bytecode carries a format version (UCODE_BYTECODE_VERSION) that an interpreter upgraded past it refuses to load, and that version is independent of libucode's PKG_ABI_VERSION/SONAME, so no package relation expresses the coupling. It is only sound when ucode and wwand are built in the same tree — which a self-built image is and a feed is not.

Good-citizen coexistence (no stock stack replaced). The packages do not CONFLICTS uqmi/umbim/comgt-ncm — they install alongside them. The netifd shim registers proto wwand and nothing else: the qmi proto name stays uqmi's, so netifd's handler load order never decides who owns an interface, and there is no switch that changes this. wwand manages only proto wwand interfaces and never adopts a bare proto qmi/mbim/ncm one, so exactly one dialer owns a given interface and the control device behind it. Handing one over is always user-triggered and rewrites it in place to proto wwand: a "Migratable interfaces" list in the LuCI modem page, the migrate ubus method / CLI, or an example uci-defaults script shipped inert under /usr/share/wwand/examples/. Nothing is installed under /etc/uci-defaults, so installing or upgrading wwand cannot rewrite an existing configuration. Inclusion is additive and opt-in per interface, not a second implementation that displaces the existing handlers.

Hardware-tested on MikroTik Chateau 5G R17 ax (Quectel RG650E, 5G NSA), Zyxel NR7101 (RG502Q), Zyxel LTE3301-Plus (EG06) and Cudy LT300 v3 (MeiG SLM770A-R), plus a GL.iNet GL-X3000 (RM520N-GL); the PCIe/MHI path (wwand-mhi) is under active validation with community testers on Foxconn T99W175 hardware. Maintained and shipped from an external feed (github.com/ddimension/openwrt-repo) while it broadens coverage and gathers field reports.

🤖 Generated with Claude Code

[BKPepe]

Thanks for working on this. I can see the motivation behind having a lightweight, event-driven WWAN manager tightly integrated with netifd, and some of the functionality here is certainly interesting.

However, I don't think this is ready to be merged into the OpenWrt packages feed in its current form.

My main concern is the scope and the amount of functionality being reimplemented. This is not merely another frontend or connection manager using the existing OpenWrt WWAN stack. wwand implements QMI, MBIM and NCM/AT itself and the corresponding packages explicitly conflict with and replace uqmi, umbim and comgt-ncm.

That effectively introduces a second implementation of a significant part of the OpenWrt WWAN stack which we would then need to maintain and review in parallel with the existing implementations.

The scope is also very large for a newly introduced project: QMI, MBIM, NCM/AT, QMAP/multiple PDP contexts, SIM/APDU handling, eSIM, SMS, telemetry, recovery, board profiles, netifd integration and automatic migration of existing configurations are all being introduced at once.

Host-side tests are useful, but they cannot replace real-world modem interoperability testing for protocols such as QMI and MBIM. The PR currently mentions production testing on four devices/modems. Considering the number of modem vendors, firmware versions, protocol quirks and failure/recovery scenarios encountered in the OpenWrt ecosystem, I don't think this provides enough coverage yet to justify replacing the established handlers.

Another concern is project maturity. This is a relatively new implementation of protocol parsers and fairly complex asynchronous state machines, and a substantial part of the implementation was AI-generated. I don't consider the use of AI itself a reason to reject code, but for this kind of low-level protocol and state-machine implementation it makes independent review and real-world validation especially important. At the moment there does not appear to be enough independent review or deployment history to establish that confidence.

There is also a broader architectural question here.

Since this project is specifically designed around OpenWrt (ucode, uloop, ubus, UCI and netifd) and aims to replace several existing OpenWrt WWAN components, I think the architecture should first be discussed with the maintainers of the existing WWAN/netifd components. In particular, it should be considered whether the missing functionality could be implemented by improving the existing stack instead of introducing another complete QMI/MBIM/NCM implementation.

Features such as better recovery, persistent context handling, QMAP support or improved netifd integration may indeed solve real shortcomings. If so, contributing those improvements to the existing components could benefit all existing users without creating two competing OpenWrt-specific WWAN stacks.

I would therefore prefer to see wwand mature as an external feed first, gain broader hardware coverage and users, accumulate real-world bug reports and fixes, and receive independent review of the protocol/state-machine implementation.

Once that has happened, and if there is consensus that maintaining a separate WWAN implementation is preferable to improving the existing stack, inclusion in the official packages feed could be reconsidered.

So for now, I would be against merging this PR. This is not because the project has no value, but because replacing several established OpenWrt WWAN components with a young and very broad implementation creates a substantial long-term maintenance and review burden that I don't think has been justified yet.

[ddimension]

Thanks for taking a deep look. This code is based on my personal QMI dial-in handler which I developed since 2014. All of my knowledge about quirks with modems is in this project.

I can understand you to not support inclusion, but is not the package feed exactly for this? Optional packages, which the user selects if he want's it. The user may use old style stack with all of it's stability problems or may use wwand instead.

So this is not about replacing, it is about giving a stable alternative with features which are needed in the field (plmn lock i.e.), that nothing else provides.
I'm also willing to provide support in future, also my company (M2M focused) stands behind this.

André

[4920441]

Since this project is specifically designed around OpenWrt (ucode, uloop, ubus, UCI and netifd) and aims to replace several
existing OpenWrt WWAN components, I think the architecture should first be discussed with the maintainers of the existing
WWAN/netifd components. In particular, it should be considered whether the missing functionality could be implemented by
improving the existing stack instead of introducing another complete QMI/MBIM/NCM implementation.

Shouldn't that only be a showstopper if wwand is set to the default install for wwan interfaces? Since there are already so much packages for manageing WWAN stuff, why is this section important for adding another package? The options you get with wwand are mostly missing on ALL other packages...

Cheers,

4920441

[openwrt-ai]

Packaging-level review of net/wwand/Makefile only — the inclusion/scope discussion in the existing review is a maintainer call and I'm not restating it.

Nothing here blocks a merge on its own. The two worth acting on regardless of how the scope question lands are the unresolvable CONFLICTS entry and the glob-then-rm split in Package/wwand/install, which can silently produce two packages owning the same path. The rest are small.

Metadata otherwise checks out: PKG_RELEASE:=1 is correct for a new package, PKG_MAINTAINER is set, the define blocks follow the 2-spaces-for-metadata / tabs-for-recipes convention, all ucode-mod-* and kmod-* dependencies resolve against openwrt main, lpac in this feed is at 2.3.0 so the >= 2.3.0 note holds, and the codeload.github.com/.../refs/tags/ source URL matches what 243 other Makefiles in this feed do. I could not verify PKG_HASH or the v1.0.0 tag — this session's GitHub access is scoped to openwrt/packages.

---

Generated by Claude Code

[ddimension]

Thanks for the very thorough and fair review — the scope and maintenance-burden concerns are legitimate, and I've reworked the most load-bearing part in response.

The biggest change: wwand no longer replaces the stock WWAN stack. I've removed all CONFLICTS (uqmi/umbim/comgt-ncm) — the packages now install alongside them. By default wwand is a good citizen:

• it manages only proto wwand interfaces and does not touch existing proto qmi/mbim/ncm interfaces;
• adopting the stock stack (registering the qmi proto alias, managing bare proto qmi, auto-migrating on upgrade) is gated behind a single global option takeover, default off;
• moving one specific interface to wwand is user-triggered (a "Migratable interfaces" list in the LuCI modem page, which converts it in place to proto wwand).

So it's no longer "a second implementation that replaces the existing handlers" — it's additive and opt-in per interface. That directly targets the "two competing OpenWrt-specific WWAN stacks" and "replacing established handlers" concerns: nothing is replaced unless the operator explicitly opts in, and the stock stack keeps owning proto qmi/mbim/ncm otherwise. I also dropped the LuCI qmi.js alias for the same reason (it collided with luci-proto-qmi), and fixed the packaging nits from the bot review (+ucode not +libucode, SUBMENU:=WWAN on wwand-esim, $(CMAKE_BINARY_DIR), the dead conflict entry).

On maturity and independent review — I fully agree these matter for low-level protocol/state-machine code. It's being maintained and shipped from an external feed (github.com/ddimension/openwrt-repo), runs on production hardware here (QMI/MBIM/NCM across several modems), and I'm actively hardening it. I'd like to keep improving it in the open rather than sit on it.

Given the coexistence rework removes the "replaces the existing stack" objection, would you be open to leaving this open for another ~2 weeks while I continue to mature it — broaden hardware coverage, gather field bug reports, and address review feedback? I'll keep the PR updated regularly as that happens. If after that you still feel the scope is too broad for the feed, I completely understand keeping it external for now.

[openwrt-ai]

Re-review of the one new commit since my last pass (d802b81, "wwand: 1.1.0 — coexist with the stock WWAN stack"). Packaging-level only; the inclusion/scope discussion is a maintainer call and I'm not restating it.

The three packaging points from the previous round are all addressed: ucode-mod-wwand-io now depends on +ucode, wwand-esim gained SUBMENU:=WWAN, and the install step uses $(CMAKE_BINARY_DIR) — which expands to $(PKG_BUILD_DIR)/build given CMAKE_BINARY_SUBDIR:=build, so the path is unchanged and now tracks L29. The dead qmi-advanced CONFLICTS entry went away with the rest of the CONFLICTS lines. The version bump keeps PKG_RELEASE:=1, which is correct for a PKG_VERSION change. Commit message matches the diff.

Nothing new blocks a merge. The one worth an answer before this lands is device ownership under the new coexistence model: CONFLICTS is what previously guaranteed only one stack could touch a given /dev/cdc-wdmX, and the replacement guarantee is a runtime property of the daemon that the packaging can't show. The takeover / proto qmi alias question is the same theme from the netifd side. The other two are nits.

Two earlier threads are still open and I haven't repeated them: the glob-then-rm split in Package/wwand/install, and the missing test-version.sh for the generic CI version check. Only the FormalityCheck jobs have reported on this head (all green), so the build/test CI hasn't exercised the latter yet.

I still can't verify PKG_HASH or the v1.1.0 tag — this session's GitHub access is scoped to openwrt/packages, so ddimension/wwand is unreachable to both the API and a plain fetch. Treat those as unchecked rather than checked-and-fine.

---

Generated by Claude Code

[openwrt-ai]

The coexistence claim here is about interfaces, but device ownership is what actually collides. The base package installs /etc/hotplug.d/usbmisc/20-wwand at Makefile:94-95 unconditionally, so the daemon gets poked for every cdc-wdm that appears, regardless of whether any interface is proto wwand. With CONFLICTS removed, the realistic install now has umbim/uqmi driving /dev/cdc-wdm0 for a proto mbim/proto qmi interface while wwand is also present on the box.

Does the daemon leave a control device completely untouched — no open, no MBIM OPEN, no QMI client allocation — when no proto wwand interface references it? If it probes on hotplug to build the modem list, two stacks are on the same cdc-wdm channel and MBIM in particular does not tolerate a second session owner. That would undercut "both stacks can be installed side by side" for exactly the users this change targets. Same question for the NCM comment at L179-182 and the AT tty hook at L101-102.

If the daemon already gates probing on the presence of a proto wwand interface (or on takeover), saying so in these comments would settle it — it is the one thing a reader can't confirm from the packaging.

---

Generated by Claude Code

[ddimension]

@-

[ddimension]

Repointed at v1.4.3, which adds the runtime half of this.

Your framing was right and the answer I gave earlier — "wwand opens a control device only for an interface it manages" — was too comfortable. Dropping the qmi alias gave exactly one owner per interface and said nothing about the device. Two holes were left: a hand-written wwand_modem could point at a node uqmi drives, and autosetup's guard recognised only cellular protos, so a proto dhcp left on wwan0 by a comgt-ncm setup did not stop it claiming that netdev.

wwand now collects every device claim made by a non-wwand interface and refuses to bind a claimed one, with the owner on the modem's control_note rather than the modem merely looking absent:

device blocklist: /dev/cdc-wdm0 (interface bt_mbim, proto mbim), wwan0 (interface bt_ncm, proto ncm), ...
modem wwmodem1: device /dev/cdc-wdm0 is owned by interface bt_mbim (proto mbim) — ignoring this modem

Coverage was read off the handlers' own proto_config_add_* lists rather than assumed, which is what caught the interesting part — the first cut would have missed the configurations that matter most:

handler	binds hardware with
qmi.sh (uqmi)	device, devpath
mbim.sh (umbim)	device, devpath
ncm.sh (comgt)	device, ifname
wwan.sh (generic)	bus — declares no device option at all

devpath is how uqmi/umbim bind by sysfs path instead of an unstable node name — the careful configuration — and wwan.sh claims hardware purely by USB bus id. Both are path-shaped, so they are normalised to the /sys/devices/-relative form and compared on the hardware path; a claim on a USB device covers its functions. A claim that resolves nowhere under /sys/devices is dropped rather than matched against everything. PROTO_DEFAULT_OPTIONS is defaultroute peerdns metric, so nothing device-shaped arrives via proto_config_add_defaults.

Two deliberate exclusions: a disabled interface claims nothing (netifd never brings it up, so a stale section must not block a device forever), and @name references an interface rather than a device.

Verified on hardware (two modems, a MikroTik Chateau): proto mbim + device, proto ncm + ifname/ctldevice all block; proto qmi + disabled 1 does not; removing the sections brings both modems back.

I am not resolving this thread, because it does not close the case you actually raised. With zero-config autosetup on — the default — a box with no wwand configuration still claims a modem nobody has claimed. What is now guaranteed is the narrower thing: wwand never takes a device somebody else has. Whether the autosetup default is right for a package that installs alongside uqmi is still the maintainer call you framed it as, and option autosetup 0 is the opt-out.

[ddimension]

Updated to wwand 1.2.0 (tag v1.2.0, PKG_HASH refreshed; the base package now also installs /usr/bin/wwandctl).

Since 1.1.0:

• modem_reattach (network re-registration without a modem reset), the wwandctl CLI, end-to-end PUK entry, SMS send, SIM slots on MBIM, PCIe/MHI (kernel wwan subsystem) discovery, stable L3 device names, FCC RF unlock, eSIM switch via lpac.
• QMI/MBIM/NCM backend parity: unified telemetry, PLMN/FPLMN lists, recovery ladder, live IP-settings refresh, last_error.
• Correctness: LTE attach-APN programmed before registration; registration reject causes surfaced; native-module hardening (OOB netlink read, missed-ACK-as-success, spawn exit-status race).
• A five-round maintainability audit: module decomposition, CI (host suite + shellcheck), ~1050 host-side checks green.

LuCI side is updated in openwrt/luci#8917.

[openwrt-ai]

Re-review of the one new commit since my last pass (345c8b1, "wwand: 1.2.0"). Packaging-level only; the inclusion/scope discussion in the maintainer review above is a maintainer call and I'm not restating it.

The bump itself is clean: PKG_RELEASE stays at 1, which is correct for a PKG_VERSION change, and the new /usr/bin/wwandctl install is properly paired with a wwandctl.uc entry in the base package's strip list, so it doesn't also leak into $(UCDIR). The commit message matches the diff. I confirmed the v1.2.0 tag exists in ddimension/wwand (resolves to commit 1d75ae8); PKG_HASH I still can't verify — codeload.github.com is not reachable from this session — so treat that one as unchecked rather than checked-and-fine.

One finding is worth acting on before merge: 1.2.0 also adds files/wwand.hotplug.wwan, a fourth hotplug script that this Makefile never installs, which leaves the "PCIe/MHI (kernel wwan subsystem) discovery" listed in the commit message working only for modems already present when the daemon starts. The other two comments are nits.

Earlier threads are still open and I haven't repeated them: the glob-then-rm split in Package/wwand/install, the missing test-version.sh (one new comment does extend that one, since 1.2.0 adds a second executable that definitely fails the generic check), the proto qmi alias ownership question under takeover, the cdc-wdm device-ownership question, and the PR body still describing the pre-1.1.0 CONFLICTS / auto-migrate model. Only the three FormalityCheck jobs have reported on this head, all green, so the build/test CI still hasn't exercised any of this.

---

Generated by Claude Code

[openwrt-ai]

Re-review of the one new commit since my last pass. 345c8b1 was amended into fc0388e (same subject, wwand: 1.2.0); the only delta against what I reviewed last time is the four-line wwan hotplug hunk in Package/wwand/install. Packaging-level only; the inclusion/scope discussion in the maintainer review above is a maintainer call and I'm not restating it.

That hunk resolves the one finding I flagged as worth acting on last round: files/wwand.hotplug.wwan is now installed to /etc/hotplug.d/wwan/20-wwand, and the paired $(INSTALL_DIR) is what arms the dispatch — procd only calls hotplug-call for a subsystem whose directory exists (hotplug.json:83-86). INSTALL_DATA matches the three sibling hotplug installs above it and the in-tree precedent for this same subsystem (modemmanager Makefile:158-160), and the filename doesn't collide with modemmanager's 25-modemmanager-wwan, so both can be installed. Commit message matches the diff, PKG_RELEASE stays at 1, which is correct for the PKG_VERSION change.

Nothing new to flag on this head. Earlier threads are still open and I haven't repeated them: the glob-then-rm split in Package/wwand/install, the missing test-version.sh (three installed executables now), the proto qmi alias ownership question under takeover, the cdc-wdm device-ownership question, the MHI kmod hint in Package/wwand-qmi/description, the bare wwand: 1.2.0 commit subject, and the PR body still describing the pre-1.1.0 CONFLICTS / auto-migrate model.

Two things I could verify last round but cannot on this one: PKG_HASH and the v1.2.0 tag. This session's GitHub access is scoped to openwrt/packages, and codeload.github.com is unreachable, so ddimension/wwand is out of reach to both the API and a plain fetch. PKG_HASH is unchanged by this amend, so nothing new rests on it — but treat it as unchecked here rather than checked-and-fine.

Only the three FormalityCheck jobs have reported on this head, all green, so the build/test CI still hasn't exercised any of this.

---

Generated by Claude Code

[ddimension]

Pushed a squashed head (8ffb9e3) that folds the 1.1.0/1.2.0 bumps back into the single wwand: add cellular connection manager commit, plus:

• net/wwand/test-version.sh — the three installed executables (wwand, wwandctl, migrate) don't print PKG_VERSION, so all six packages opt out of the generic runtime version check (no grep -q, per the feed convention).
• MHI kmods — Package/wwand-qmi/description now points PCIe/MHI users at kmod-mhi-wwan-ctrl (+ kmod-mhi-net / kmod-mhi-pci-generic); no hard dep, since most users are on USB.

Answering the two open questions, since they're the ones that can't be read off the packaging:

proto qmi ownership under takeover. netifd sources /lib/netifd/proto/*.sh in sorted glob order, and wwand.sh sorts after qmi.sh, so when option takeover '1' makes both call add_protocol qmi, wwand's handler registers last and deterministically owns proto qmi. With takeover off (default) wwand.sh never emits add_protocol qmi at all, so uqmi keeps it — that's the intended coexistence. takeover is meant for a box being switched to wwand.

cdc-wdm device ownership. wwand opens a control device only when a wwand_modem section references it (then start_modem runs) or zero-config autosetup creates one. A device that no wwand config references is never opened — no MBIM OPEN, no QMI client, nothing. Autosetup only fires on an unconfigured box, and I just tightened its occupancy gate (ddimension/wwand@abeb0bd) so an existing proto mbim/ncm interface counts as "configured" too (it previously keyed off proto wwand/qmi + a wwan0 section, which caught the common case by interface name but not a stock umbim/comgt-ncm interface under another name). So with umbim/uqmi/comgt-ncm owning a cdc-wdm for their own interface, wwand leaves it untouched until that interface is explicitly migrated to proto wwand. That fix will ride the next point release the PKG pin tracks; happy to bump the pin here once tagged if you'd prefer it in-tree first.

glob-then-rm in Package/wwand/install. Agreed this is the least tidy part. Explicit enumeration was the first thing I tried, but the base package is ~54 .uc files (38 in src-ucode/, 16 under codec/), so listing them just moves the hand-synced list to the other side — a new base file would then be the thing silently dropped. The clean fix is the one you suggested: lay src-ucode/ out in per-backend subdirectories so each package globs its own directory and the base can't leak a backend file. That's an upstream reorg (it touches every import path), so I've queued it rather than trade one sync hazard for another; the backend packages already enumerate explicitly, so the split fails loudly at install (duplicate path) rather than shipping wrong-but-working.

[openwrt-ai]

Re-review against the new head. The branch was squashed since my last pass — the four commits I had reviewed (fc0388e and its ancestors) are now the single commit 8ffb9e3, "wwand: add cellular connection manager". Diffing fc0388e..8ffb9e3 on net/wwand/, the only content delta is two things, both closing threads from earlier rounds:

• net/wwand/test-version.sh (new) — opts all six binary packages out of the generic version check. It follows the in-tree $PKG_NAME case/*)-fallback shape (e.g. libs/expat/test-version.sh), has no grep -q, and lists every package the Makefile builds, so the *) branch can't fire.
• Package/wwand-qmi/description (L130-134) — the MHI kmod hint. All three names check out against openwrt main: kmod-mhi-wwan-ctrl, kmod-mhi-net, kmod-mhi-pci-generic.

The squash also resolved the bare-wwand: 1.2.0 subject nit on its own. The single commit's message matches its diff, and PKG_RELEASE:=1 is correct for a new package. Nothing new blocks a merge; the one comment below is a nit.

Worth noting because it changes what is actually verified: the full build CI has now run on this head and is green on all ten architectures, so test-version.sh is confirmed working rather than assumed — the x86_64 runtime job logs wwand-qmi: Version test override script found and [pass] Version check override for each package, then All tests passed. (The * Failed to connect to ubus lines around the wwand post-install/pre-deinstall in that log are just default_postinst's "$i" start on a procd init script in a container with no ubus — not a defect here.) lpac in this feed is still at 2.3.0, so the >= 2.3.0 note in Package/wwand-esim/description continues to hold.

Earlier threads are still open and I'm not repeating them: the glob-then-rm split in Package/wwand/install, the proto qmi alias ownership question under takeover, the cdc-wdm device-ownership question, the qmi-advanced mention that survives in the L121 prose, the ucode-mod-io reuse question, and the PR body still describing the pre-1.1.0 CONFLICTS / auto-migrate model. The scope and inclusion discussion in the maintainer review above is a maintainer call and I'm not restating it.

PKG_HASH and the v1.2.0 tag I still cannot check — this session's GitHub access is scoped to openwrt/packages, so ddimension/wwand is unreachable to both the API and a plain fetch. Neither changed in this delta, but treat them as unchecked rather than checked-and-fine.

---

Generated by Claude Code

[ddimension]

Updated to wwand 1.3.0 (tag v1.3.0, PKG_HASH refreshed), which resolves the open packaging threads — most of them by the source-tree reorg that was queued last round:

• glob-then-rm in Package/wwand/install → gone. src-ucode/ is now laid out so each package installs an explicit per-file list (WWAND_BASE_UC / _CODEC / _SCHEMA for the base; the backends enumerate their own modules). Every module is owned by exactly one package, so a new backend file can never silently land in the base. This is the reorg suggested in that thread.
• A second native I/O module vs. the stock ucode-mod-io. wwand_io.so is message-framed cdc-wdm/tty transport plus an rmnet/QMAP netlink helper — not the byte-stream file I/O the stock module offers — so it can't be replaced by it. To stop it looking like a general-purpose module, it's no longer a separate package: it ships inside the wwand base (wwand-private, version-locked to the ucode side), with PROVIDES:=ucode-mod-wwand-io so older configs keep resolving.
• PCIe/MHI drivers. New wwand-mhi package carries the MHI bus/PCI/control/data kmods as DEPENDS and ships the kernel-wwan-subsystem hotplug (/etc/hotplug.d/wwan/20-wwand) — the fourth hotplug script that the base install was missing. It is transport-only/backend-neutral; pair it with wwand-qmi or wwand-mbim. The USB backends keep their USB-only kmod deps.
• wwand-esim SUBMENU:=WWAN added, so it no longer lands directly under Network.
• removed a leftover internal project-name reference from the description and PR text (it was never a package).
• Coexistence vs. device ownership. The base hotplug opens a control device only when a wwand_modem section references it (or zero-config autosetup creates one on an otherwise-unconfigured box); a device owned by umbim/uqmi/comgt-ncm for their own interface is left untouched until that interface is explicitly migrated to proto wwand.
• test-version.sh covers the new package set (the three installed executables — wwand, wwandctl, migrate — don't print PKG_VERSION).

New in 1.3.0 as well: the ucode tree ships precompiled to bytecode by default (repo-root CMakeLists, built next to wwand_io.so), with a configure-time capability probe that falls back to shipping source when the host ucode can't emit bytecode — so the build never fails on an older toolchain; CONFIG_WWAND_UCODE_SOURCE forces source.

On the broader architecture question: I'd still welcome a discussion with the WWAN/netifd maintainers. wwand is deliberately additive here (opt-in per interface, nothing replaced by default), and I'm happy to feed back any of the recovery / persistent-context / QMAP / netifd-integration work into the existing stack where that's the better home.

[liaohongxing]

I very much welcome and look forward to this component, because the existing proto_qmi, proto_mbim, and proto_ncm only implement basic connection functionality, lacking a GUI interface and advanced features such as band locking, SMS reading, signal strength, etc. This component can provide unified management and reduce the learning cost for users. As for the possibility that the author might stop maintaining it in the future, we can simply remove this package then.

[openwrt-ai]

Re-review against the new head. The branch was squashed again — 8ffb9e3 is now the single commit 8e33265 with the same subject, so I diffed 8ffb9e3..8e33265. The delta is the 1.3.0 bump plus four structural changes: the ucode tree is now precompiled to bytecode by a repo-root cmake build (PKG_BUILD_DEPENDS:=ucode/host, UCODE_COMPILER/UCODE_PRECOMPILE, the new CONFIG_WWAND_UCODE_SOURCE opt-out), the base install switched from glob-then-rm to explicit WWAND_BASE_UC/_CODEC/_SCHEMA lists, ucode-mod-wwand-io was folded into the base package (PROVIDES:=ucode-mod-wwand-io) and replaced in the package set by the new wwand-mhi transport bundle, which is also where the wwan hotplug now lives. Packaging-level only; the inclusion/scope discussion in the maintainer review above is a maintainer call and I'm not restating it.

Three earlier threads close with this head, and the replacements check out: the base package no longer installs anything a backend owns; wwand-mhi's DEPENDS names four kmods that all exist in openwrt main, including kmod-mhi-wwan-mbim, which answers the MBIM-over-MHI question I raised last round; and test-version.sh was updated in step with the package set (wwand-mhi in, ucode-mod-wwand-io out), so the *) fallback still cannot fire. The single commit's message matches its diff and PKG_RELEASE:=1 is correct for a new package, so no commit checks.

What is new is that the default build path changed shape. Three of the comments below are questions about that path — bytecode/interpreter skew, whether the SDK's host ucode can compile modules that import ubus/uci/uloop/rtnl, and whether a precompiled main.uc is still directly executable as /usr/sbin/wwand. None is a defect I can demonstrate from the packaging alone, and each has a one-line answer if the upstream build already handles it; I raise them because bytecode is the default while every build and runtime test this PR has accumulated so far exercised the source path, and only the three FormalityCheck jobs have reported on this head. The other two comments are nits.

Earlier threads I'm not repeating: the proto qmi alias ownership under takeover and the cdc-wdm device-ownership question (both answered in the PR conversation but the threads are still open), and the PR body still describing the pre-1.1.0 CONFLICTS / auto-migrate model.

PKG_HASH and the v1.3.0 tag remain unchecked — this session's GitHub access is scoped to openwrt/packages, so ddimension/wwand is unreachable to both the API and a plain fetch. Treat them as unverified rather than verified-fine.

---

Generated by Claude Code

[ddimension]

Repointed at wwand v1.4.2 (was v1.4.1). Still one commit; only PKG_VERSION/PKG_HASH moved.

The release adds one thing: status() now reports proto_switch, a per-model flag for whether the modem has a control-protocol switch recipe (QMI <-> MBIM). It is needed by the companion LuCI PR (openwrt/luci#8917), where the switch was being offered whenever the modem currently spoke QMI or MBIM — which is nearly every modem and says nothing about whether the switch exists for that hardware. The capability already existed in the daemon (protocol_switch_supported()); it was simply never surfaced, so no UI could gate on it.

Built against the real tarball before pushing, same as last round — make package/feeds/wwand/wwand/compile on the openwrt-25.12 aarch64_cortex-a53 SDK: PASS, six apks at 1.4.2-r1.

Tarball is 2.0 MB, unchanged from 1.4.1 (the vendor manual that made up 61% of 1.4.0 is gone as of 1.4.1). Please do not use v1.4.0.

[openwrt-ai]

Re-review against the new head. The branch was squashed again — the four commits ending at 0f8b8c5 are now the single commit b28b266, so I diffed 0f8b8c5..b28b266. The delta is 23 lines in net/wwand/Makefile (the 1.3.0 → 1.4.2 bump, the PKG_BUILD_DEPENDS gating, three comment-block repairs) plus a mode change on test-version.sh. Packaging-level only; the inclusion/scope discussion in the maintainer review above is a maintainer call and I'm not restating it.

The blocking finding from last round is genuinely closed, and this time I could verify it rather than infer it — ddimension/wwand is reachable over plain git from this session. Against tag v1.4.2 (421b034fd7cd85ddfa26deb46df4e6fe222ddd3e):

• files/examples/99-wwand-migrate exists, so Package/wwand/install can succeed against the tarball this Makefile downloads.
• files/wwand-proto.sh contains a single add_protocol wwand and no takeover / add_protocol qmi at all. The rewritten comments at L146-148 and L188-192 now describe the packaged source rather than the upstream default branch, which is what the previous round's second finding was about.
• Every path the install sections name resolves: 38 WWAND_BASE_UC + 4 WWAND_BASE_CODEC + 13 WWAND_BASE_SCHEMA entries, main.uc, wwandctl.uc, the qmi/mbim/ncm/esim module lists, codec/mbim_schema/*.uc (six files), and the eight files/ entries. Cross-checking the union against src-ucode/ there are no duplicates and no orphans — every .uc in the release is owned by exactly one package. That is the invariant the explicit-list rework was for, and it holds exactly on this release.

Also checked on this head: PKG_RELEASE:=1 is correct for a new package; the single commit's message matches its diff, so no commit checks; lpac in this feed is still 2.3.0, so the >= 2.3.0 note in Package/wwand-esim/description continues to hold; files/wwand.init is procd-based with USE_PROCD=1, start_service() and the #!/bin/sh /etc/rc.common shebang; test-version.sh gained the executable bit, which is the majority mode for that filename in this feed (69 of 101) and has no grep -q. Upstream's CMakeLists.txt return()s before touching the ucode compiler when UCODE_PRECOMPILE=OFF, so the now-default source path needs no host ucode at configure time either.

One finding is worth acting on: the PKG_BUILD_DEPENDS gating at L42 does not do what it looks like — it drops ucode/host unconditionally, so selecting CONFIG_WWAND_UCODE_PRECOMPILE silently ships source instead of bytecode. That suggestion was mine last round and it was wrong; the correction and the working idiom are inline. The other comment is a nit on the PR body.

PKG_HASH remains the one thing I cannot check: codeload.github.com is blocked for this session even though the git endpoint is not, so the tarball itself is out of reach. Treat it as unverified rather than verified-fine.

Earlier thread still open and not repeated here: the cdc-wdm device-ownership question — the PR conversation now answers it plainly rather than closing it ("zero-config autosetup is on by default … the runtime default currently leans toward claiming"), which is the honest answer and a maintainer call.

Only the three FormalityCheck jobs have reported on this head, all green. The build/runtime CI has not run since 8ffb9e3, so neither the current install lists nor the source-default build path have been exercised by CI.

---

Generated by Claude Code

[ddimension]

Repointed at wwand v1.4.3. One commit still; only PKG_VERSION/PKG_HASH moved in the Makefile.

The release adds a device blocklist: wwand refuses to bind hardware that another interface in /etc/config/network names, logs the claim set once at start, and surfaces the owner on the modem's control_note. That is the runtime half of the device-ownership question in the thread above — details and the honest limit are there rather than repeated here.

Built against the real tarball before pushing, as with the previous rounds: make package/feeds/wwand/wwand/compile on the openwrt-25.12 aarch64_cortex-a53 SDK, PASS, six apks at 1.4.3-r1. Tarball 2.0 MB.

Release note that still stands: please do not use v1.4.0 — it carries a 2.6 MB vendor AT manual that a git add -A of mine had picked up. Untracked since v1.4.1.

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The branch was squashed again — b28b266 is now the single commit 732e490 with the same subject, so I diffed b28b266..732e490. The whole delta is 12 lines in net/wwand/Makefile: the 1.4.2 → 1.4.3 bump (PKG_VERSION, PKG_HASH) and the PKG_BUILD_DEPENDS rewrite. Packaging-level only; the inclusion/scope discussion in the maintainer review above is a maintainer call and I'm not restating it.

The blocking finding from last round is fixed, and the fix is the right idiom. PKG_BUILD_DEPENDS:=WWAND_UCODE_PRECOMPILE:ucode/host (L48) is exactly what the metadata scan expects: package-metadata.pl splits condition:dep at package-metadata.pl:528, then get_conditional_dep / and_condition emit $(if $(CONFIG_WWAND_UCODE_PRECOMPILE),$(curdir)/package/utils/ucode/host/compile) into tmp/.packagedeps, where .config is loaded — so the gate arms at the point the $(if …) wrapper could not. The ucode/host half resolves too: ucode declares $(eval $(call HostBuild)), which is what the !$deptype || grep {…} buildtypes check at package-metadata.pl:539-544 requires. In-tree precedent for the same form: unetd, iucode-tool, policycoreutils.

Re-verified against the release this now pins. Tag v1.4.3 exists in ddimension/wwand (45ae5ca0cbb86f7a2d760c984484874b3c71ccbc), and against that tree:

• Every path the install sections name resolves — 38 WWAND_BASE_UC + 4 WWAND_BASE_CODEC + 13 WWAND_BASE_SCHEMA, main.uc, wwandctl.uc, the qmi/mbim/ncm/esim lists, codec/mbim_schema/*.uc, and all eight files/ entries including files/examples/99-wwand-migrate. Cross-checking the union against src-ucode/: no duplicates and no orphans — all 80 .uc files in the release are owned by exactly one package. v1.4.2 → v1.4.3 adds no new modules (it only grows existing files), so the explicit lists did not need to move with the bump, and they didn't.
• main.uc / wwandctl.uc still carry #!/usr/bin/env ucode, which the source-default path (WWAND_UCODE=$(PKG_BUILD_DIR)/src-ucode) installs verbatim to /usr/sbin/wwand and /usr/bin/wwandctl.
• add_subdirectory(io) precedes the if(NOT UCODE_PRECOMPILE) return() in the repo-root CMakeLists.txt, so $(CMAKE_BINARY_DIR)/io/wwand_io.so is still produced on the now-default -DUCODE_PRECOMPILE=OFF path. On the opt-in path the probe's source fallback copys the .uc files into ${UCODE_OUT}, so WWAND_UCODE is populated in that branch too — neither branch can leave Package/wwand/install staring at a missing tree.
• PKG_RELEASE:=1 is correct for the PKG_VERSION change, the commit message matches its diff (no commit checks), test-version.sh still names all six packages so the *) branch cannot fire, and lpac in this feed is still 2.3.0, so the >= 2.3.0 note in Package/wwand-esim/description continues to hold.

Worth noting for the one thread still open — the cdc-wdm device-ownership question — 1.4.3 is where its runtime half landed, and it is more thorough than the last exchange suggested: config.uc now collects device/ifname/ctldevice and the path-shaped devpath/bus claims from every enabled non-wwand interface, daemon.uc refuses to bind a modem whose device or sysfs path matches one (surfacing it as a control_note rather than silently idling), and autosetup_create bails on any pre-existing qmi/mbim/ncm interface before it gets as far as the device check. devpath matters because uqmi's qmi.sh sets no_device=1 and can be configured by devpath alone; that spelling is covered. I raise none of it as a finding — it's the maintainer's call whether it settles the thread.

PKG_HASH is the one thing I still cannot check: codeload.github.com is blocked for this session even though the git endpoint is not, so the tarball itself is out of reach. Treat it as unverified rather than verified-fine.

Only the three FormalityCheck jobs have reported on this head, all green. The build/runtime CI has not run since 8ffb9e3, so neither the current install lists nor the source-default build path have been exercised by CI.

---

Generated by Claude Code

[ddimension]

Repointed at v1.4.5.

Please note the previous pin was invalidated, and why. The v1.4.0–v1.4.3
tags were rewritten to drop a 2.6 MB vendor PDF that had been committed by
accident (it was 61% of the release tarball). Rewriting published tags is not
something I'd normally do, and I should have caught the file before tagging —
but the alternative was leaving a large binary in every tarball a maintainer
would download. The consequence is that the PKG_HASH this PR pinned for
v1.4.3 no longer matches what codeload serves, so the build would have failed
its hash check. If you fetched that tarball earlier, it is not the one you would
get now.

v1.4.5 is a fresh tag on top of the rewritten history and will not be moved.

What it adds since v1.4.3, all from a hardware session on an NCM modem:

• Both AT ports are read for URCs. An unopened port is not merely unparsed — it
  is unread, and one of the two modems tested sends its bearer notification on
  the second port only.
• The modem-reset GPIO no longer inverts its polarity when two pulses overlap.
  It derived the resting level from the current pin level, so a second pulse
  sampled a line the first was still driving and left the modem held in reset.
• An ifdown survives a daemon restart. Operator intent lived only in the
  daemon's memory; netifd's runtime autostart flag is the durable record, and
  it stays true through device loss so this cannot swallow a reconnect.
• Registration <stat> 9/10 (CSFB not preferred) are full data registrations
  and were being treated as unregistered; 6/7/8/11 are attachments no PDP
  context can live on and are reported as restricted rather than as failures.
• Commands a firmware refuses outright are retired instead of retried forever.

No packaging changes: the diff against the previous head is PKG_VERSION and
PKG_HASH. The SYMBOL:pkg form for PKG_BUILD_DEPENDS and the comment-block
corrections from the earlier review are already in the pinned tree.

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The branch was squashed again — the delta since my last pass (4e7d45d, v1.3.0) is the single commit d6b13de, "wwand: add cellular connection manager", a 1.3.0 → 1.4.5 bump. Diffing 4e7d45d..d6b13de on net/wwand/, the content changes are three structural inversions plus a mode bit, and each one closes a thread I had open:

• Bytecode is now opt-in, source is the default. CONFIG_WWAND_UCODE_SOURCE (opt-out) became CONFIG_WWAND_UCODE_PRECOMPILE (opt-in, default n), WWAND_UCODE (L58) now falls back to $(PKG_BUILD_DIR)/src-ucode unless precompile is set, and PKG_BUILD_DEPENDS is gated as WWAND_UCODE_PRECOMPILE:ucode/host so a default build no longer pulls host ucode. This answers the three questions I raised on the 1.3.0 round: the default path no longer depends on the SDK host ucode's bytecode-emit capability, there is no bytecode/interpreter-skew on a plain feed install, and the installed /usr/sbin/wwand + /usr/bin/wwandctl are readable .uc with a #!/usr/bin/env ucode shebang, i.e. directly executable. The SYMBOL:pkg conditional-build-depends form is the correct one here and the comment's DUMP=1 rationale is accurate.

• The takeover / proto qmi alias is gone. The shim now registers proto wwand and nothing else; the ownership-under-takeover thread is resolved by removal rather than by argument.

• No /etc/uci-defaults hook. The auto-migrate 99-wwand-migrate is no longer installed under /etc/uci-defaults; it ships inert under /usr/share/wwand/examples/ (files/examples/99-wwand-migrate, #!/bin/sh), so installing/upgrading wwand cannot rewrite an existing config. The PR body was rewritten to match.

PKG_RELEASE:=1 is correct for the PKG_VERSION change and the single commit's message matches its diff, so no commit checks. I re-checked packaging completeness against the v1.4.5 source tree: every file the install sections reference exists, and all 56 top-level ucode modules plus the codec/schema/mbim_schema files map to exactly one package (38 base + main.uc/wwandctl.uc as executables + 5 qmi + 6 mbim + 3 ncm + 2 esim) — no orphaned or double-owned module.

Verification status changed for the better this round: the v1.4.5 tag now resolves in ddimension/wwand (annotated tag 4701bca → commit b5c9bb6), which I could not reach in earlier rounds. PKG_HASH I still cannot byte-verify — the codeload.github.com archive endpoint is not reachable from this session — and the full build/runtime CI has not run on this head (only the three FormalityCheck jobs, all green), so treat both the hash and the source-default build path as unexercised-by-CI rather than confirmed.

The cdc-wdm device-ownership question (a runtime property of the daemon, answered in the PR conversation) and the scope/inclusion discussion in the maintainer review above remain a maintainer call; I'm not restating them.

---

Generated by Claude Code

[patrakov]

Here is my addition to the findings by the AI reviewer. It reviewed the coexistence model (based on blocklisting device nodes) with older uqmi/umbim/comgt-ncm protos, but completely forgot about protos 3g, directip, and modemmmanager. The first two live in the comgt package, same as ncm. The third one is in modemmanager.

Check if the existing code covers these extra setups.

[ddimension]

@patrakov Thank you — one of the three was a real hole. Checked all of them
against their handlers rather than reasoning about them:

3g and directip (comgt) — both declare device:device and set
no_device=1, so the value is a device node. That is the spelling the
blocklist already collects, alongside ifname/ctldevice. Covered, no change
needed.

modemmanager — not covered, and it was the one case the design could not
see. It declares a plain device (no :device suffix) and puts a sysfs
path in it — modemmanager.sh says so directly, # validate sysfs path given in config, then passes the value to mmcli --modem="${device}". A sysfs path
can never match a /dev node or a netdev name, so the string was collected and
then compared against things it could not equal. A proto modemmanager
interface claimed its modem entirely invisibly to wwand.

Fixed in v1.4.6, which this PR now pins: a device value under /sys/ is
additionally recorded as a path-shaped claim and resolved through the same
claim_path() / same_hw_path() comparison as uqmi's devpath and
wwan.sh's bus — so a claim on a USB device also covers its functions.

Keyed on the /sys/ prefix rather than on the proto name, deliberately:
mmcli --modem= also accepts a modem index or a D-Bus path, and neither of
those names hardware that anything on the box could resolve. Blocking on them
would look safer and would in fact be wrong.

Your framing exposed the general shape of the mistake, which is worth stating
plainly: I had been enumerating protocols and asking which options each one
uses, when the invariant that actually matters is what kind of value an option
holds. device is not always a device name. The three spellings the blocklist
now understands — device node, netdev name, hardware path — cover the handlers
in tree today, but the next handler to appear will be checked against that
question rather than added to a list.

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The branch was squashed again — the delta since my last pass (d6b13de, v1.4.5) is the single commit f2b7a26, same subject. Diffing d6b13de..f2b7a26 on net/wwand/, the whole change is four lines: PKG_VERSION 1.4.5 → 1.4.7 and the matching PKG_HASH. PKG_RELEASE:=1 is correct for a new package, and the commit message matches its diff, so no commit checks. Packaging-level only; the scope/inclusion discussion in the maintainer review above is a maintainer call and I'm not restating it.

Verified against the release this now pins. Tag v1.4.7 exists in ddimension/wwand (annotated tag 3becd75 → commit 4134174), and comparing that tree with v1.4.5:

• No files were added or removed upstream — v1.4.5..v1.4.7 touches only src-ucode/config.uc, daemon.uc, main.uc, telemetry_ncm.uc plus docs and tests. That is the thing a bump can silently break here, since every package installs an explicit per-file list rather than a glob: a new module would ship in no package at all. Re-running the ownership check against v1.4.7 anyway — 38 WWAND_BASE_UC + 4 WWAND_BASE_CODEC + 13 WWAND_BASE_SCHEMA, main.uc, wwandctl.uc, the qmi/mbim/ncm/esim lists and codec/mbim_schema/*.uc — gives no duplicates and no orphans: every .uc in the release is owned by exactly one package. All eight $(PKG_BUILD_DIR)/files/... paths resolve too, including files/examples/99-wwand-migrate.
• No new module or binary dependency. The only native ucode modules the tree pulls are fs, struct, uloop, ubus, uci, rtnl (via require('rtnl') in netlink.uc) and wwand_io — all covered by DEPENDS on the base package. The four dynamic require()s of wwand's own modules (wwand.atport, codec.schema.loc_lazy, codec.schema.wms_lazy, wwand.esim_bridge) each resolve to a file some package installs, so lazy loading can't hit a module that shipped nowhere. The upstream delta adds no external-binary spawn, so nothing new is owed a DEPENDS entry.
• main.uc and wwandctl.uc still start with #!/usr/bin/env ucode, so the source-default path installs them directly executable as /usr/sbin/wwand and /usr/bin/wwandctl.
• test-version.sh is unchanged and still names all six packages, so the *) branch cannot fire; lpac in this feed is still 2.3.0, so the >= 2.3.0 note in Package/wwand-esim/description continues to hold.

PKG_HASH is the one thing I still cannot check: codeload.github.com is blocked by this session's egress policy (403 on the archive URL) even though the git endpoint for the same repo is reachable, so the tarball itself is out of reach. Treat it as unverified rather than verified-fine.

Only the three FormalityCheck jobs have reported on this head, all green. The full build/runtime CI has not run since 8ffb9e3, so neither the current install lists nor the source-default build path have been exercised by CI.

The cdc-wdm device-ownership thread remains open and answered in the conversation rather than closed — a maintainer call; I'm not restating it. The one comment below is a nit.

---

Generated by Claude Code

[openwrt-ai]

nit: the PR body has drifted behind this line again — it says "Current release: v1.4.5 — the release this Makefile pins", but this pins 1.4.7. Same mismatch I raised on the b28b266 round (body said v1.3.0 against a v1.4.2 pin); that one was fixed by updating the body, and it has fallen behind by two releases once more.

Everything else in the body still matches the Makefile (source-by-default with CONFIG_WWAND_UCODE_PRECOMPILE opt-in, no CONFLICTS, explicit per-file install lists, the inert examples/ migrate script), so this is just the one number. Purely cosmetic — it does not affect what gets built.

---

Generated by Claude Code