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

Since v1.6.0 the QMI mux datapath is an interface rather than a hard-coded branch: rmnet, qmimux and the MBIM session mux are entries in it, and wwand-qmi additionally carries two plug-ins for the out-of-tree vendor QMAP drivers (qmi_wwan_q, pcie_mhi). Neither driver exists in the kernel tree, so on an OpenWrt kernel both plug-ins are inert — their probe finds none of the children those drivers would have registered and declines, leaving the built-in datapaths in charge. 1.6.0 also fixes the QMAP data-aggregation constant: QMAPV5 was 8, which is libqmi's QMAPv4, so modems declined it and every QMI link silently fell back to plain QMAP.

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

[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

[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]

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]

Re-review against the new head. My last pass was d99277e; the branch was squashed again into 881679d9 with the same subject, and diffing d99277e..881679d9 the entire delta is seven lines of prose in Package/wwand-mhi/description — the AT-over-MBIM paragraph moved out of the advisory voice and now names the USB cost, which is what the open thread from last round asked for. No metadata, dependency or install-list change. 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 and inclusion discussion in the maintainer review above is a maintainer call and I'm not restating it.

Nothing here blocks a merge. The one comment below is a nit on that same paragraph.

Verification I could not do last round, and can now. github.com/ddimension/wwand is reachable over plain git from this session again, so the check that has been "internal consistency only" for the last two rounds is a real one against the pinned release:

• Tag v1.5.2 exists and resolves to d74e999531d747e4e5f34dd6b00d20722b85f879.
• Module ownership on v1.5.2 is exact. All 82 .uc files in src-ucode/ are installed by exactly one package — no orphans, no duplicates, and nothing the Makefile names is missing from the release. That includes atcmd_mbim.uc / atcmd_mbim_lazy.uc, the pair that shipped nowhere at v1.5.1; the wwand-mbim entries added for them (L249-250) close that finding against the actual tree rather than by inspection of the Makefile alone.
• All eight $(PKG_BUILD_DIR)/files/... paths resolve, including files/examples/99-wwand-migrate (#!/bin/sh), so the inert-example install cannot fail.
• main.uc and wwandctl.uc still start with #!/usr/bin/env ucode, so the source-default path (WWAND_UCODE=$(PKG_BUILD_DIR)/src-ucode) installs them directly executable as /usr/sbin/wwand and /usr/bin/wwandctl.

PKG_HASH remains the one thing I cannot check: codeload.github.com answers the archive URL with an access-denied JSON body rather than a tarball for this session, even though the git endpoint for the same repo is reachable. 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 (the 1.3.0 head), so the current default build path — ucode source, precompile off, no host ucode staged — is still unexercised by this repo's CI.

Earlier threads still open and not repeated here: the cdc-wdm device-ownership question, the ucode-mod-io reuse question, the deferred backend/transport split (answered in the thread as a follow-up rather than a change here), and — now only for the opt-in precompile path — the host-ucode capability and bytecode/interpreter-skew questions.

---

Generated by Claude Code