oonfeeWRT v0.1.8

v0.1.8 is a patch release correcting two edge cases. The Devices page now handles an LLDP ownership ledger whose controller-added package list is null, and configured radios that share one physical PHY keep their distinct UCI wifi-device section identities through probe, Preview, and Apply.

This release adds no database migration, router permission, automatic package action, or new configuration authority. Database schema remains 25.

Prepared September 17, 2026. Publication is established only by a completed exact v0.1.8 tag workflow and the GitHub release. Source notes, pull-request checks, or a tag alone do not establish that artifacts are ready. Verify standalone archives with SHA256SUMS and verify the container's keyless signature, provenance, SBOM, and immutable digest.

LLDP device-page rendering

Issue #40 reported that opening a device could crash when an existing LLDP capability record contained a null controller-added package list. The Devices view now normalizes a null or absent list to an array before rendering it. A null, absent, or empty list is shown as Controller-added packages: none recorded, not “already installed.” PR #41 carries the change.

Upgrading and refreshing the browser is sufficient for this rendering fix. Do not reinstall LLDP, reset the controller, or re-adopt the device. The stored LLDP state, error details, exact package-plan consent, ownership record, and rollback behavior are unchanged.

This fix does not claim that every LLDP installation failure is solved. Feed, package-index, authentication, service, interface-configuration, and verification failures continue to use their existing error and recovery paths.

Shared-PHY radio targeting

Issue #39 identified a device with multiple configured radios backed by the same physical PHY. A PHY-derived identity could make those separate radios resolve to the same UCI target. v0.1.8 instead preserves the actual configured wifi-device section key reported by luci-rpc.getWirelessDevices and uses it as the authoritative target. Runtime interface and PHY names remain observations, not substitutes for that configured identity. PR #42 carries the correction.

The renderer rejects invalid, duplicate, or ambiguous radio identities before building a partial desired document or making router writes. Legacy records may bridge to a section identity only when the correspondence is unique; the controller does not guess between multiple radios on one PHY.

For a device affected by the earlier behavior:

1. Upgrade to v0.1.8 and refresh the browser.
2. Use Re-probe capabilities on the affected device.
3. Generate a fresh Preview and confirm that every intended WLAN names the correct, distinct radio target. Review all changes, conflicts, and omissions.
4. Select Apply only after the fresh plan is unambiguous and explicitly authorized.

Do not edit the controller database, clear ownership records, or re-adopt the device as a workaround. A previous failed or unknown Apply may already have changed router configuration; inspect the router's current state independently and compare it with the fresh Preview instead of assuming no change or blindly repeating Apply. If Preview still reports an ambiguous, duplicate, or invalid target—or the displayed targets are not distinct—stop without applying and request help using sanitized compatibility evidence and redacted Preview/error details.

Upgrade and rollback

v0.1.6 or v0.1.7 → v0.1.8 stays on database schema 25. The upgrade adds no migration, re-adoption, ACL refresh, LLDP package action, new permissions, or automatic desired-configuration Apply. Deploy the verified binary or pinned container with the same data volume and runtime passphrase, then refresh the browser. After startup, normal polling resumes. On preexisting managed devices, when the write gate is open, existing automatic 802.11k neighbour reconciliation may update runtime hostapd neighbour lists; monitor-only devices remain excluded.

Before upgrading, retain a stopped, consistent database plus its matching keyring, runtime passphrase, and the old binary or image as one rollback unit. Returning to v0.1.6 or v0.1.7 does not cross a schema boundary, but replacing only the executable is not a complete recovery plan. Never run two controllers against the same data directory.

Upgrades from v0.1.5 still run the existing ordered 23 → 24 → 25 migrations. A v0.1.5 binary cannot open schema 24 or 25; rollback to it requires the untouched matching schema-23 database, keyring, runtime passphrase, and v0.1.5 binary or image. Do not edit schema metadata to force a downgrade.

Follow docs/installation/upgrades.md and the bundled INSTALL.md for verified installation, backups, recovery, and rollback procedures.

Validation and evidence limits

• The exact PR #41 validation commit 9be9b46 was independently confirmed against a genuine stored LLDP ledger containing a null added-package list. The device view rendered none recorded without changing the ledger or performing an LLDP action.
• Reporter @flubba confirmed exact PR #42 commit b3b7adf on a Tenda BE12 Pro with MT7996/MT7992E radios. Re-probe and Preview preserved distinct targets; a no-op Apply retained unique ownership rows. The router's configuration had already been corrected with an older patch, so this is not fresh-write hardware proof.
• September 17 read-only checks exercised login, identity, LAN evidence, probe, render, and Preview on a Linksys WRT3200ACM and TP-Link Archer C6 v2 running OpenWrt 25.12.5. Both devices reported separate PHY/radio targets. Each Preview contained zero set/add/prune operations, no conflicts, and one omission. No Apply, restart, package, or network change was performed. These were separate-PHY checks, not physical shared-PHY validation.
• Both exact pull-request heads passed GitHub CI before merging. The completed exact-tag workflow remains the independent publication gate for v0.1.8; these preparation results do not claim that the final tag or artifacts are already published.

The September 12 v0.1.7 Precision screenshots remain representative; these behavior fixes require no replacement captures. See docs/releases/v0.1.7.md for the retained Precision interface and schema-25 feature set. Existing firmware, integration, topology, telemetry, security, and hardware-validation limits remain unchanged.