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, 2935 host-side checks run without hardware). Current release: v1.5.2 — 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

[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

[ddimension]

Fixed, and the pin moved on since: the Makefile now pins 1.4.9 and the body says "Current release: v1.4.9 — the release this Makefile pins". The stale check count went with it (2856 -> 2935).

Worth saying plainly, since this is the third time the body lagged the pin: the drift is not an oversight in one direction, it is that the two live in different places and only one of them is in the diff you review. The release procedure here now treats the body as part of the bump rather than as prose, so a pin change that leaves it behind is an incomplete change.

[simsasss]

Hi,
I'm playing a bit with your project, looks really good idea. Also found some bugs:
RUTM11 ramips hardware:

root@OpenWrt:~# /etc/init.d/wwand restart
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.132421] do_page_fault(): sending SIGSEGV to ucode for invalid read access from 77b693e0
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.140931] epc = 77dbab65 in libucode.so.20230711[19b65,77da1000+22000]
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.147731] ra  = 77dba967 in libucode.so.20230711[19967,77da1000+22000]

[simsasss]

root@OpenWrt:~# Thu Aug 27 13:27:04 2026 daemon.warn wwand[4399]: modem wwmodem0: uim read of file 6f60 failed: { "error": "qmi", "result": 1, "code": 48 }
Thu Aug 27 13:27:09 2026 daemon.warn wwand[4399]: modem wwmodem0: at: timeout waiting for reply to AT+CPLS=0
Thu Aug 27 13:27:09 2026 daemon.warn wwand[4399]: modem wwmodem0: at: AT+CPLS=0 -> error: timeout
Thu Aug 27 13:27:17 2026 daemon.warn wwand[4399]: modem wwmodem0: at: timeout waiting for reply to AT+CPOL?
Thu Aug 27 13:27:17 2026 daemon.warn wwand[4399]: modem wwmodem0: at: AT+CPOL? -> error: timeout
Thu Aug 27 13:27:17 2026 daemon.warn wwand[4399]: modem wwmodem0: uim read of file 6f61 failed: { "error": "qmi", "result": 1, "code": 48 }
Thu Aug 27 13:27:17 2026 daemon.warn wwand[4399]: modem wwmodem0: uim read of file 6f62 failed: { "error": "qmi", "result": 1, "code": 48 }
Thu Aug 27 13:27:17 2026 daemon.warn wwand[4399]: modem wwmodem0: uim read of file 6f7b failed: { "error": "qmi", "result": 1, "code": 48 }
Thu Aug 27 13:27:25 2026 daemon.warn wwand[4399]: modem wwmodem0: at: timeout waiting for reply to AT+CRSM=176,28539,0,0,12
Thu Aug 27 13:27:25 2026 daemon.warn wwand[4399]: modem wwmodem0: at: AT+CRSM=176,28539,0,0,12 -> error: timeout

[ddimension]

Hi simass,

thanks for testing.
this ist just probing. Never mind. Not all modems support the full set of commands.
Everything else worked fine?

[ddimension]

Hi, I'm playing a bit with your project, looks really good idea. Also found some bugs: RUTM11 ramips hardware:

root@OpenWrt:~# /etc/init.d/wwand restart
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.132421] do_page_fault(): sending SIGSEGV to ucode for invalid read access from 77b693e0
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.140931] epc = 77dbab65 in libucode.so.20230711[19b65,77da1000+22000]
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.147731] ra  = 77dba967 in libucode.so.20230711[19967,77da1000+22000]

Plese send more logs and used version. Thanks a lot!

[simsasss]

Plese send more logs and used version. Thanks a lot!

OpenWrt SNAPSHOT r35944-a865bd92e2
wwand-2026.08.26~648283c2-r41 mipsel_24kc {/feed/wwand} (GPL-2.0-only) [installed]
wwand-mbim-2026.08.26~648283c2-r41 mipsel_24kc {/feed/wwand} (GPL-2.0-only) [installed]
wwand-qmi-2026.08.26~648283c2-r41 mipsel_24kc {/feed/wwand} (GPL-2.0-only) [installed]

Its enough to execute /etc/init.d/wwand restart and it gets segfault, what exact logs would you like to get?

Everything else worked fine?

Kind of, testing it out right now, I will add more comments :)

1. Buttons go out of frame.

2. After entering pin code modem attached to operator, but connection failed:

Thu Aug 27 13:57:22 2026 daemon.info wwand[4010]: modem wwmodem_auto: state INIT_SERVICES -> SIM_UNLOCK
Thu Aug 27 13:57:22 2026 kern.info kernel: [  692.552224] 8021q: adding VLAN 0 to HW filter on device wwand0
Thu Aug 27 13:57:22 2026 daemon.info wwand[4010]: modem wwmodem_auto: state SIM_UNLOCK -> SIM_BLOCKED
Thu Aug 27 13:58:28 2026 daemon.warn wwand[4010]: modem wwmodem_auto: manual PIN release requested (entering PIN past the low-retry guard)
Thu Aug 27 13:58:28 2026 daemon.info wwand[4010]: modem wwmodem_auto: state SIM_BLOCKED -> ABSENT
Thu Aug 27 13:58:28 2026 daemon.info wwand[4010]: modem wwmodem_auto: state ABSENT -> INIT_TRANSPORT
Thu Aug 27 13:58:29 2026 daemon.info wwand[4010]: modem wwmodem_auto: state INIT_TRANSPORT -> INIT_SERVICES
Thu Aug 27 13:58:29 2026 daemon.notice wwand[4010]: modem wwmodem_auto: mbim device EG060K-EA, imei xxxxxxxxxxxxxxx, imsi ?, iccid xxxxxxxxxxxxxx
Thu Aug 27 13:58:29 2026 daemon.notice wwand[4010]: modem wwmodem_auto: AT port: /dev/ttyUSB0
Thu Aug 27 13:58:34 2026 daemon.warn wwand[4010]: modem wwmodem_auto: at: timeout waiting for reply to AT+QMBNCFG="AutoSel",1
Thu Aug 27 13:58:34 2026 daemon.warn wwand[4010]: modem wwmodem_auto: at: AT+QMBNCFG="AutoSel",1 -> error: timeout
Thu Aug 27 13:58:34 2026 daemon.warn wwand[4010]: modem wwmodem_auto: at: AT+QMBNCFG="AutoSel",1 failed: { "error": "timeout" }
Thu Aug 27 13:58:37 2026 daemon.warn wwand[4010]: modem wwmodem_auto: at: timeout waiting for reply to AT+CGMI
Thu Aug 27 13:58:37 2026 daemon.warn wwand[4010]: modem wwmodem_auto: at: AT+CGMI -> error: timeout
Thu Aug 27 13:58:37 2026 daemon.notice wwand[4010]: modem wwmodem_auto: datapath: cdc_mbim, parent wwand0, mux []
Thu Aug 27 13:58:37 2026 daemon.info wwand[4010]: modem wwmodem_auto: state INIT_SERVICES -> SIM_UNLOCK
Thu Aug 27 13:58:37 2026 daemon.notice wwand[4010]: modem wwmodem_auto: sim: pin accepted
Thu Aug 27 13:58:39 2026 daemon.info wwand[4010]: modem wwmodem_auto: state SIM_UNLOCK -> REGISTERING
Thu Aug 27 13:58:39 2026 daemon.info wwand[4010]: modem wwmodem_auto: state REGISTERING -> ATTACHING
Thu Aug 27 13:58:39 2026 daemon.notice wwand[4010]: modem wwmodem_auto: registered: plmn "Telia LT", roaming false
Thu Aug 27 13:58:39 2026 daemon.info wwand[4010]: modem wwmodem_auto: state ATTACHING -> READY
Thu Aug 27 13:58:39 2026 daemon.info wwand[4010]: autosetup: no APN-table match for wwan0 (iccid xxxxxxxxxx, imsi ?) — keeping the SIM-provisioned attach

It connected after restart of netifd interface.

[simsasss]

I tried to use multiplexing, it is working with one profile.
As I understand it needs only mux channel to be set, but if I create second interface modem is dropped from "system"

Modems page:

[simsasss]

Daemon fails to recover after deleting all configuration with multiplexing:

Thu Aug 27 14:23:47 2026 kern.info kernel: [   44.802555] usb 1-2: new high-speed USB device number 2 using xhci-mtk
Thu Aug 27 14:23:47 2026 kern.notice kernel: [   44.953291] usb 1-2: config 1 has an invalid interface number: 8 but max is 6
Thu Aug 27 14:23:47 2026 kern.notice kernel: [   44.960510] usb 1-2: config 1 has an invalid interface number: 9 but max is 6
Thu Aug 27 14:23:47 2026 kern.notice kernel: [   44.967831] usb 1-2: config 1 has an invalid interface number: 9 but max is 6
Thu Aug 27 14:23:47 2026 kern.notice kernel: [   44.975102] usb 1-2: config 1 has an invalid interface number: 12 but max is 6
Thu Aug 27 14:23:47 2026 kern.notice kernel: [   44.982338] usb 1-2: config 1 has no interface number 4
Thu Aug 27 14:23:47 2026 kern.notice kernel: [   44.987656] usb 1-2: config 1 has no interface number 5
Thu Aug 27 14:23:47 2026 kern.notice kernel: [   44.992985] usb 1-2: config 1 has no interface number 6
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.013640] option 1-2:1.0: GSM modem (1-port) converter detected
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.020362] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.028448] option 1-2:1.1: GSM modem (1-port) converter detected
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.035509] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.043827] option 1-2:1.2: GSM modem (1-port) converter detected
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.050734] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB2
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.059140] option 1-2:1.3: GSM modem (1-port) converter detected
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.066190] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB3
Thu Aug 27 14:23:47 2026 daemon.info wwand[2540]: hotplug add ttyUSB0
Thu Aug 27 14:23:47 2026 daemon.warn wwand[2540]: modem wwmodem_auto: control interface not present yet, waiting for hotplug
Thu Aug 27 14:23:47 2026 daemon.warn wwand[2540]: interface wwan0: modem wwmodem_auto not started
Thu Aug 27 14:23:47 2026 daemon.info wwand[2540]: hotplug add ttyUSB1
Thu Aug 27 14:23:47 2026 daemon.warn wwand[2540]: modem wwmodem_auto: control interface not present yet, waiting for hotplug
Thu Aug 27 14:23:47 2026 daemon.warn wwand[2540]: interface wwan0: modem wwmodem_auto not started
Thu Aug 27 14:23:47 2026 daemon.info wwand[2540]: hotplug add ttyUSB2
Thu Aug 27 14:23:47 2026 daemon.warn wwand[2540]: modem wwmodem_auto: control interface not present yet, waiting for hotplug
Thu Aug 27 14:23:47 2026 daemon.warn wwand[2540]: interface wwan0: modem wwmodem_auto not started
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.538783] cdc_mbim 1-2:1.8: setting rx_max = 16384
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.544805] cdc_mbim 1-2:1.8: cdc-wdm0: USB WDM device
Thu Aug 27 14:23:47 2026 kern.info kernel: [   45.551669] cdc_mbim 1-2:1.8 wwan0: register 'cdc_mbim' at usb-1e1c0000.xhci-2, CDC MBIM, 6a:aa:8f:c8:88:24
Thu Aug 27 14:23:48 2026 daemon.info wwand[2540]: hotplug add ttyUSB3
Thu Aug 27 14:23:48 2026 daemon.warn wwand[2540]: modem wwmodem_auto: control interface not present yet, waiting for hotplug
Thu Aug 27 14:23:48 2026 daemon.warn wwand[2540]: interface wwan0: modem wwmodem_auto not started
Thu Aug 27 14:23:48 2026 daemon.info wwand[2540]: hotplug add cdc-wdm0
Thu Aug 27 14:23:48 2026 daemon.warn wwand[2540]: modem wwmodem_auto: control interface not present yet, waiting for hotplug
Thu Aug 27 14:23:48 2026 daemon.warn wwand[2540]: interface wwan0: modem wwmodem_auto not started
Thu Aug 27 14:23:48 2026 daemon.info wwand[2540]: hotplug add wwan0
Thu Aug 27 14:23:48 2026 daemon.warn wwand[2540]: modem wwmodem_auto: control interface not present yet, waiting for hotplug
Thu Aug 27 14:23:48 2026 daemon.warn wwand[2540]: interface wwan0: modem wwmodem_auto not started
Thu Aug 27 14:23:50 2026 authpriv.info dispatcher.uc: luci: accepted login on /admin/network/wwand for root from 192.168.1.95
Thu Aug 27 14:23:52 2026 daemon.warn wwand[2540]: modem wwmodem_auto: control interface not present yet, waiting for hotplug
Thu Aug 27 14:24:22 2026 daemon.warn wwand[2540]: modem wwmodem_auto: control interface not present yet, waiting for hotplug

[ddimension]

Hi!

Thanks for all the detailed reports. I could identify the problems, hopefully mips also.
Repo should be updated in 8h, please give it a retry. Please give feedback again so I can update PR.

Hi, I'm playing a bit with your project, looks really good idea. Also found some bugs: RUTM11 ramips hardware:

root@OpenWrt:~# /etc/init.d/wwand restart
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.132421] do_page_fault(): sending SIGSEGV to ucode for invalid read access from 77b693e0
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.140931] epc = 77dbab65 in libucode.so.20230711[19b65,77da1000+22000]
Thu Aug 27 13:24:16 2026 kern.info kernel: [  869.147731] ra  = 77dba967 in libucode.so.20230711[19967,77da1000+22000]

[openwrt-ai]

Re-review against the new head. The branch was squashed again — my last pass was f2b7a26 (v1.4.7), and the delta is the single commit c96f904 with the same subject. Diffing f2b7a26..c96f904 on net/wwand/, the whole packaging change is two lines: PKG_VERSION 1.4.7 → 1.5.1 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.

One finding, and it is precisely the failure mode the explicit-per-file install lists exist to make visible. Every bump I have checked so far added no ucode modules, so the lists never had to move. 1.5.0 does add two — src-ucode/atcmd_mbim.uc and src-ucode/atcmd_mbim_lazy.uc, the AT-over-MBIM transport — and the install lists did not move with them, so those two files ship in no package at all. Because modem_common.uc (base package) require()s the shim unguarded, that is a runtime throw on any modem with no AT tty, not merely a missing feature. Details and a suggestion are inline; the second comment is a question about which package should carry them once they are packaged, given that the modems this transport was written for are wwand-mhi + wwand-qmi installs.

Verified against tag v1.5.1, which exists in ddimension/wwand (annotated tag 28f73a2 → commit fc013f1):

• Ownership check: 80 of the 82 .uc files in the release are owned by exactly one package, with no duplicates. The only two orphans are the pair above; nothing named by the Makefile is missing from the release. Upstream's CMakeLists.txt module lists were updated for both files, which is what makes the omission here a packaging-side gap rather than an upstream one.
• No new dependency is owed. The tree imports only the native modules fs, struct, ubus, uci, uloop plus rtnl (via require() in netlink.uc) and wwand_io — all covered by the base package's DEPENDS. v1.4.7..v1.5.1 adds no external-binary spawn; the patches/kernel/ directory it adds is documentation for users patching their own kernel, not something the packaging installs.
• All eight $(PKG_BUILD_DIR)/files/... paths resolve, including files/examples/99-wwand-migrate; main.uc and wwandctl.uc still start with #!/usr/bin/env ucode, so the source-default path installs them directly executable.
• 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.
• The PR body's "Current release: v1.5.1 — the release this Makefile pins" matches this head, so the drift nit from earlier rounds stays closed.

PKG_HASH is the one thing I still cannot check: codeload.github.com returns 403 for this session's egress policy 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 — which is why the orphaned modules above went unnoticed by anything but a read of the release tree.

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

---

Generated by Claude Code

[openwrt-ai]

The 1.4.7 → 1.5.1 bump added two ucode modules that no package in this Makefile installs: src-ucode/atcmd_mbim.uc and src-ucode/atcmd_mbim_lazy.uc (the AT-over-MBIM transport, new in 1.5.0). Cross-checking the union of WWAND_BASE_UC/_CODEC/_SCHEMA and the four backend install lists against the v1.5.1 tree, these are the only two orphans — the other 80 .uc files are each owned by exactly one package, and nothing named here is missing upstream. Upstream's own build lists were updated for both (CMakeLists.txt:86, CMakeLists.txt:114); the explicit per-file lists here were not, which is exactly the drift the explicit-list design is meant to surface.

The consequence is a runtime failure, not just a missing feature. modem_common.uc is in WWAND_BASE_UC, and it require()s the shim unguarded at modem_common.uc:985 and :1006 — the path open_at() takes whenever a modem has no AT tty. Unlike the backend loader in daemon.uc:23-42, which wraps require() in try/catch so a missing backend package "surfaces as a status note instead of a failure", there is no guard here, so this throws on a module that shipped nowhere instead of falling through to o.next().

The shim's own header says which package should own it — "it lives in the wwand-mbim package (it needs mbim_client + codec/mbim)" (atcmd_mbim_lazy.uc:5-7) — and atcmd_mbim.uc imports wwand.mbim_client and wwand.codec.mbim, both wwand-mbim files. atcmd_mbim.uc is an ES module and atcmd_mbim_lazy.uc a plain script, matching how mbim_lazy.uc is already handled, so both install the same way:

Suggested change

	$(INSTALL_DATA) $(WWAND_UCODE)/mbim_lazy.uc $(1)$(UCDIR)/
	$(INSTALL_DATA) $(WWAND_UCODE)/mbim_lazy.uc $(1)$(UCDIR)/
	$(INSTALL_DATA) $(WWAND_UCODE)/atcmd_mbim.uc $(1)$(UCDIR)/
	$(INSTALL_DATA) $(WWAND_UCODE)/atcmd_mbim_lazy.uc $(1)$(UCDIR)/

---

Generated by Claude Code

[ddimension]

Both orphaned — thank you, this was a real packaging hole and not a cosmetic one. Fixed: wwand-mbim now installs atcmd_mbim.uc and atcmd_mbim_lazy.uc alongside mbim_lazy.uc.

They were added upstream in 1.5.0 and the bump here only moved PKG_VERSION/PKG_HASH, so the file lists never followed. The consequence was worse than a missing feature: modem_common.uc reaches the AT-over-MBIM pipe through require('wwand.atcmd_mbim_lazy'), so on an MBIM-driven modem the require would have thrown out of open_at rather than degrading.

I checked the rest of the tree the same way rather than fixing just the two you named — every .uc in src-ucode/ is now referenced by some install section, so there are no other orphans.

[openwrt-ai]

Follow-on question to the orphaned-module comment above: once atcmd_mbim*.uc is packaged into wwand-mbim, does an MHI modem still reach it?

The AT-over-MBIM transport exists primarily for this package's hardware. Its header explains that the generic Qualcomm MHI profile "declares DIAG/MBIM/QMI/IPCR/FIREHOSE/IP_SW0/IP_HW0 but no DUN channel, and DUN is what mhi_wwan_ctrl turns into /dev/wwanNat0" (atcmd_mbim.uc:6-11) — so a QMI-driven MHI modem has no AT tty and falls into the discovery.wwan_sibling_port(self.device, 'mbim', …) branch, opening the sibling MBIM node purely as an AT side-channel. wwand-mhi already pulls kmod-mhi-wwan-mbim, so the kernel side of that node is covered here, but DEPENDS is +wwand only, and the install this package's own description recommends for such a modem is wwand-mhi + wwand-qmi — which would carry neither atcmd_mbim.uc nor its mbim_client/codec/mbim imports.

Is +wwand-mbim meant to be part of wwand-mhi's DEPENDS (or at least hinted at in its description, the way the MHI pairing hint was added to the qmi/mbim descriptions), or is the AT-over-MBIM path only expected to be reachable on MBIM-driven modems? Asking rather than asserting because the answer depends on how much of the vendor telemetry / protocol-switch / AT+QSIMDET path you consider load-bearing for a QMI-over-MHI install.

---

Generated by Claude Code

[ddimension]

It does not, and that is the sharper half of the question — thank you.

atcmd_mbim needs the MBIM client and codec, so wwand-mbim is where it belongs. But an MHI modem driven over QMI installs wwand-qmi + wwand-mhi, and nothing there pulls wwand-mbim in. That combination is precisely where the pipe is wanted, because the generic Qualcomm entry in mhi-pci-generic declares no DUN channel and such a modem therefore has no AT port at all.

Two changes, upstream in the tree this pins next:

1. The require is no longer bare. It now follows the shape daemon.uc already uses for the backend packages (lazy_backend): try once, remember the failure, and report the capability as absent with a log line naming the package to install. So the missing package is a limitation, not a traceback — the same contract the control backends already have.

2. wwand-mhi's description says so: adding wwand-mbim is worthwhile even on a QMI-driven MHI modem, because it is what makes AT reachable at all there.

I deliberately did not make wwand-mhi DEPEND on wwand-mbim. It would pull the whole MBIM backend onto every MHI box for a fallback that many will not need — some MHI modems do expose DUN, and a kernel that declares the channel gives them a real AT port, which is better than the pipe anyway (full duplex, and it carries URCs, which a request/response pipe cannot).

[openwrt-ai]

Re-review against the new head. The branch was squashed again — 4e7d45d and the commits that followed it are now the single commit d99277e, same subject — so I diffed 4e7d45d..d99277e. Two files: the 1.3.0 → 1.5.2 bump plus the precompile inversion in net/wwand/Makefile, and a 644 → 755 mode change on test-version.sh. Packaging-level only; the scope and inclusion discussion in the maintainer review above is a maintainer call and I'm not restating it.

Nothing here blocks a merge. Both comments below are questions, and the second is arguably a design preference rather than a defect.

Earlier threads that close on this head

• The gated ucode/host build dependency now actually arms. The $(if $(CONFIG_...),ucode/host) form I flagged last round was dropped for WWAND_UCODE_PRECOMPILE:ucode/host (L48), and that prefix form is honoured: gen_package_mk splits each Build-Depends entry on : into condition and package (package-metadata.pl:523-531) and feeds the condition to get_conditional_dep, which emits $(if $(CONFIG_WWAND_UCODE_PRECOMPILE),$(curdir)/package/utils/ucode/host/compile) into .packagedeps — evaluated with .config included, so the DUMP=1 problem does not apply. In-tree precedent for the same shape: elfutils/Makefile:25 (!USE_GLIBC:argp-standalone). The explanatory comment at L43-47 is accurate.
• The orphaned AT-over-MBIM modules are packaged. atcmd_mbim.uc and atcmd_mbim_lazy.uc now install in wwand-mbim (L249-250). Cross-checking the union of WWAND_BASE_UC/_CODEC/_SCHEMA and the four backend install lists, no module is claimed by two packages.
• The comment blocks that still described bytecode as the default are all rewritten consistently — L15-22, L53-58, L65-66 and L86-88 now agree with each other, with the $(if ...) at L67 and with default n at L95.
• /etc/uci-defaults/99-wwand-migrate is gone; the script ships inert under /usr/share/wwand/examples/ (L158-164), which matches both the commit message and the PR body.
• The PR body no longer lags the pin — it says v1.5.2 and L27 pins 1.5.2. That is the fourth round this drifted and the first where it did not.

test-version.sh is unchanged apart from the mode; it still names all six packages the Makefile builds, so the *) fallback cannot fire, and 755 is the majority mode for this file in the feed (71 of 104). PKG_RELEASE:=1 is correct for a new package, and the single commit's message matches its diff — no commit checks.

What I could not verify

PKG_HASH and the v1.5.2 tag remain unchecked. This session's GitHub access is scoped to openwrt/packages; codeload.github.com answers the tarball URL with an access-denied JSON body rather than an archive, so ddimension/wwand is out of reach to both the API and a plain fetch. For the same reason I could not repeat the orphaned-module cross-check against the actual 1.5.2 src-ucode file list — the check above is internal consistency only, not "every shipped module is installed by exactly one package". Same for files/examples/99-wwand-migrate existing at this tag. Treat all of these 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 (the 1.3.0 head), so the build path that is now the default — ucode source, precompile off, no host ucode staged — has never been exercised in this repo's CI. That is the ground for the first comment below.

Earlier threads still open and not repeated here: the cdc-wdm device-ownership question, the ucode-mod-io reuse question, whether the SDK's host ucode (built UBUS_SUPPORT=OFF/UCI_SUPPORT=OFF/ULOOP_SUPPORT=OFF/RTNL_SUPPORT=OFF) can compile the modules that import those, and the bytecode/interpreter-skew question — the last two now apply only to the opt-in path, which lowers their stakes considerably.

---

Generated by Claude Code

[openwrt-ai]

UCODE_COMPILER is still passed unconditionally, but the binary it names is no longer guaranteed to exist. Until this head, PKG_BUILD_DEPENDS:=ucode/host (unconditional) made $(STAGING_DIR_HOSTPKG)/bin/ucode present for every build; now that L48 gates it on WWAND_UCODE_PRECOMPILE, the default build stages no host ucode at all, so cmake is configured with -DUCODE_COMPILER=<path that does not exist> -DUCODE_PRECOMPILE=OFF.

That is fine if the repo-root CMakeLists.txt only touches UCODE_COMPILER inside if(UCODE_PRECOMPILE) — the comment at L53-58 says the capability probe is on the opt-in path, which implies it does — but a bare find_program()/execute_process() or an if(NOT EXISTS ${UCODE_COMPILER}) at top level would fail configure on the path that is now the default. Can you confirm the option is unused when UCODE_PRECOMPILE=OFF?

Worth an explicit answer because nothing has built this configuration yet: the only full build/runtime CI run on this PR was on 8ffb9e3, where bytecode was the default and ucode/host was an unconditional build dependency. Every head since has only had the three FormalityCheck jobs report, so the source-default + no-host-ucode combination has never been exercised here.

(The gating change itself is correct — see the review body.)

---

Generated by Claude Code

[openwrt-ai]

This now recommends wwand-mbim to users who have no USB modem, and wwand-mbim hard-requires the USB MBIM transport: DEPENDS:=+wwand-qmi +kmod-usb-net-cdc-mbim. Following the advice on a PCIe/MHI box therefore drags in kmod-usb-net-cdc-mbim and, through it, kmod-usb-wdm, kmod-usb-net-cdc-ncm, kmod-usb-net-cdc-ether, kmod-usb-net and kmod-mii — none of which the modem uses, since the transport on this path is kmod-mhi-wwan-mbim, which wwand-mhi already pulls.

The sharper edge is availability rather than size: that chain ends at kmod-usb-core, which is DEPENDS:=@USB_SUPPORT, so on a target built without USB support wwand-mbim is not selectable at all and the AT-over-MBIM capability this paragraph describes is simply unreachable — even though everything it actually needs (mbim_client.uc, codec/mbim*, atcmd_mbim*.uc, kmod-mhi-wwan-mbim) is available there.

The ucode side of wwand-mbim is transport-neutral; only the kmod line is not. Is the intent that MHI users accept the USB kmods, or should the cdc-mbim dependency move so the MBIM control backend and the USB transport can be selected separately (the way wwand-mhi already separates transport from backend)? Not prescribing a shape — it's your call whether that is worth a package split. Flagging it because the recommendation is new on this head and pushes users into exactly that combination.

---

Generated by Claude Code