oonfeeWRT v0.1.5

v0.1.5 expands one controller beyond one routed subnet without turning every router into a configuration target. A device can now be adopted as Managed or Monitor only. The controller still permits at most one managed Gateway, but it can poll and display multiple reachable monitor-only routers across routed management networks. This release also adds reusable, exact-MAC policy sets, a more consistent responsive interface, and a documented feasibility boundary for future flow visibility.

oonfeeWRT manages stock OpenWrt through existing SSH/ubus interfaces. It is not firmware and installs no controller-authored executable on a router.

Released September 10, 2026. The stable v0.1.5 tag workflow publishes the release archives and OCI image. Verify downloaded archives with SHA256SUMS; the published OCI image also carries a keyless signature, SBOM, and provenance attestation.

Highlights

• Monitor-only adoption: choose Monitor only when a reachable OpenWrt router belongs in inventory, telemetry, and topology but its desired configuration must remain outside oonfeeWRT. Events remain visible. Multiple monitor-only routed devices and subnets are supported; network reachability or an existing VPN is still required.
• One configuration authority: a site still has at most one Managed Gateway. Monitor-only devices are excluded from Preview, Apply, site configuration controls, optional LLDP installation/configuration/removal, and wireless-neighbor mutations. Backend checks enforce those boundaries even if a request bypasses the UI.
• Explicit bootstrap impact: monitor-only adoption is not zero-touch. After the operator reviews and acknowledges the plan, adoption still creates the scoped rpcd login and installs the distinct read-only oonfeewrt-monitor ACL group needed for polling. It does not take ownership of router configuration, install a package, or authorize a later Apply.
• Reusable policy sets: create, rename, update, list, and delete named sets of canonical, exact client MAC addresses. Firewall rules can reference a set through source_set_id; the concrete members are resolved and validated before rendering.
• Safer Object Manager workflow: the Secure action can draft policy for a reusable set instead of forcing repeated per-client rules. The Master Table resolves set-backed policy so reviewers can see the concrete affected clients before Preview and Apply.
• Policy lifecycle guards: empty or malformed sets, unknown references, and ambiguous source definitions fail closed. A set cannot be removed while a rule still references it. Each MAC needs a stored local observation from the currently adopted Managed Gateway. Monitor-only observations neither satisfy nor contaminate that proof. Missing proof makes set creation/update, MAC-based Secure drafts, and active-MAC Preview fail closed. Policy-set changes remain controller-side intent; they do not write a router until the ordinary reviewed Preview/Apply flow.
• UI consistency: page headers, actions, status treatments, and responsive layouts are aligned across Dashboard, Devices, Topology, Radios, Policy Engine, Settings, and adoption. Monitor-only state is named in the adoption flow and device inventory. Light and dark themes and desktop/mobile browser paths receive regression coverage.
• Flow visibility is still a feasibility track: v0.1.5 documents storage, package, performance, privacy, and truthful-claim gates for a future pilot. It does not install nlbwmon, netifyd, or another DPI/flow package and does not ship application identification.

Managed and monitor-only devices

Management mode is independent of the Gateway, Access point, and Switch capability labels:

Mode	Included	Excluded
Managed	Polling, inventory, telemetry, events, topology, and—when selected and supported—reviewed desired configuration	Nothing beyond the normal capability, ownership, and permission limits
Monitor only	Polling through the distinct read-only oonfeewrt-monitor ACL, inventory, telemetry, events, topology evidence including existing LLDP observation, a separately acknowledged RF scan when supported, scoped ACL maintenance, and un-adoption	Preview, Apply, desired/site configuration controls, optional LLDP install/config/remove mutations, wireless-neighbor mutations, and other package/config/remove operations

Monitor only limits persistent configuration authority; it does not make every observation passive. An acknowledged RF scan is an active, transient observation that can take a serving radio off-channel and pause, roam, or disconnect clients. It has no intended persistent configuration change and retains the same capability and disruption gates as a managed-device scan.

Use monitor-only mode for a routed site, upstream router, or separately administered OpenWrt device whose evidence should appear in the controller. oonfeeWRT does not discover or create routes between subnets: the controller host must already reach every management address, and firewalls must permit the documented SSH/bootstrap and HTTP or HTTPS /ubus paths.

Only a managed device may own the Gateway responsibility used for site intent and WAN health. Additional routers can be monitor only; they do not become backup gateways, DHCP authorities, multi-WAN members, or configuration targets. Changing a device's role in a real network should begin with a fresh backup and a review of which system owns DHCP, routing, firewall, and wireless state.

Reusable policy sets

A policy set is a controller object with a stable ID, a human-readable name, and exact canonical MAC members. It is not a VLAN, dynamic identity group, hostname matcher, application group, or router-resident address set.

Rules may use either their existing source fields or source_set_id, never an ambiguous mixture. During validation and rendering, oonfeeWRT resolves the set to its concrete MAC members. Preview therefore remains the decision boundary: review the expanded clients, zones, protocol, ports, action, target device, and redacted UCI diff before Apply.

Deleting a referenced set is refused. Removing or changing a member updates controller intent only; it does not silently push a router change. Generate a new Preview and explicitly Apply to reconcile the managed Gateway.

Every member must exist in observed inventory and have a stored This network (local) observation from the currently adopted Managed Gateway. Schema 23 stores source-relative scope and last_seen by (device_id, MAC). Monitor-only observations neither satisfy nor contaminate that proof, including after un-adoption. After an upgrade, portable restore, or normal provenance- retention expiry, policy-set create/update, direct-MAC and set-backed Secure compilation, and Preview with active MAC firewall/block/fixed-address intent fail closed until a successful managed-Gateway poll re-observes each MAC. Portable restore deliberately clears source-relative observations from the prepared destination database; evidence gathered by the source controller is not portable write authority. Authorization rejects observations older than 30 days or more than five minutes in the future independently of cleanup. Blocked/fixed-address intent can still be cleared one client at a time. Use a network/zone or explicit IPv4 scope when policy crosses a device boundary.

Upgrade and rollback

Create and verify a portable backup before upgrading. For a direct rollback, also stop v0.1.4 and retain its raw database/keyring pair or a consistent whole- volume snapshot, plus the matching runtime passphrase. A portable backup can instead be restored through a separate clean v0.1.4 controller; there is no public command that extracts it into an old live data directory.

v0.1.5 migrates the controller database from schema 20 to schema 23 in three ordered steps:

1. schema 20 → 21 adds management_mode; every existing device becomes Managed, preserving v0.1.4 behavior;
2. schema 21 → 22 adds reusable policy sets and firewall-rule set references;
3. schema 22 → 23 adds per-device client provenance, its MAC lookup index, and the case-insensitive global-client MAC index used by bounded policy checks. It drops the legacy Gateway index before canonicalizing the compatibility role, then rebuilds the one-managed-Gateway uniqueness guard from both functions_json and role, so the representations cannot disagree and bypass the limit.

The migrations do not configure routers, install packages, remove user data, or reinterpret existing devices as monitor only. The v0.1.4 binary cannot open a schema-23 database. Rolling back therefore requires the matching pre-upgrade schema-20 database, keyring, and passphrase, or restoration of the portable backup into clean v0.1.4 state. Replacing only the binary or image tag is not a valid rollback.

See the bundled INSTALL.md (source: docs/INSTALL.md) for verified download, container, backup, restore, signature, and rollback commands.

Validation and known evidence limits

The release workflow covers Go tests and race detection, UI unit and browser tests, dependency and secret scans, a fresh documentation dependency install, documentation OSV audit, VitePress production build, release archive smoke tests, backup/restore compatibility, and multi-platform image publication. The separate documentation workflow repeats its audit/build checks on pull requests and main and publishes Pages from main; verify it is green before tagging. Together those checks prove source, documentation, and release contracts; they are not a substitute for a physical-router test.

• The v0.1.4 transitive topology correction remains source- and candidate-tested. Final retest on the reporter's multi-router hardware in issue #25 is pending.
• A live delegated IPv6 prefix and full end-to-end IPv6 client path remain unproved on release hardware.
• Three-or-more-AP fan-out, real mesh backhaul, wireless uplink, literal peer isolation, and the full Filogic/class-B resource envelope still require the documented hardware proofs.
• Monitor-only behavior is automated-test covered. It does not claim that every routed firewall, VPN, or OpenWrt target permits the required management traffic.

Security and scope

• Monitor-only is enforced at both presentation and desired-configuration boundaries. Its acknowledged bootstrap installs the scoped login and distinct read-only oonfeewrt-monitor ACL; explicit ACL maintenance and un-adoption remain available, but the mode does not authorize site configuration, optional LLDP install/config/remove mutations, wireless-neighbor mutations, or other package/config/remove operations. Existing LLDP observation remains available.
• Policy sets contain exact MAC identifiers. They are policy selectors, not authentication: MAC addresses can be observed or spoofed on a network.
• Adoption, Apply, management-LAN IPv6 changes, RF scans, speed tests, and optional capability installation retain their separate plan, acknowledgement, audit, and ownership boundaries.
• The HTTP listener has no native TLS. The supplied Compose file publishes on host loopback unless OONFEE_HTTP_BIND explicitly selects another address; use a trusted reverse proxy before remote access.
• Custom policy routing, mwan3, multi-WAN health/failover, bonding, manual WAN selection, gateway-run speed tests, DPI, and application-flow history remain outside this release.
• No independent security audit or penetration test has been completed.