v0.1.3

oonfeeWRT v0.1.3

v0.1.3 is a patch release focused on correctly identifying the Internet uplink
on PPPoE and other OpenWrt systems where more than one logical interface reports
a default route. It manages stock OpenWrt through existing SSH/ubus interfaces;
it is not firmware and installs no controller-authored executable on a router.

Publication is complete only when the v0.1.3 tag workflow succeeds. Verify
downloaded archives with SHA256SUMS; the published OCI image also carries a
keyless signature, SBOM, and provenance attestation.

Highlights

• The controller now selects the unique usable, lowest-metric IPv4 default from
  the installed main routing table instead of trusting netifd interface order.
  A modem-management network can no longer win merely because it appears as
  another default-route candidate.
• PPPoE logical and runtime identities are mapped correctly. For example,
  logical wan can be associated with kernel device pppoe-wan, allowing the
  Dashboard and device-detail traffic charts to use the counters that actually
  exist.
• Route and logical-interface evidence are treated as one observation. Missing,
  malformed, ambiguous, or inconsistent evidence is reported as unavailable
  while the last proved cache is preserved; the controller does not guess.
• The Device Detail API exposes the proved WAN series key explicitly. The field
  is additive, and the UI retains a compatibility fallback when connected to an
  older controller that does not provide it.
• Added reporter-shaped DrayTek-management plus PPPoE regression coverage,
  lower-metric route selection, equal-metric ambiguity, direct-interface
  fallback, composite-source failure, and rolling API/UI compatibility tests.

Issue #20 supplied the
real OpenWrt route evidence used to reproduce this failure mode.

Routing scope

v0.1.3 observes one effective main-table IPv4 default route. Ordinary single
DHCP, static, and PPPoE uplinks are supported. Equal-metric distinct defaults,
ECMP/multipath, and kernel devices that cannot be mapped to exactly one active
OpenWrt logical interface are left unavailable instead of being selected by
iteration order.

Custom policy routing, mwan3, per-uplink health, manual WAN selection, and
bond-member monitoring are not modeled by this release. A policy-selected path
may differ from the main-table route. Route evidence is collected on the slower
network/topology cycle, so this is not a rapid failover monitor.

Upgrade and rollback

Back up the matching database/keyring pair before upgrading. v0.1.2 and v0.1.3
both use schema 19, so this upgrade requires no database migration and adds no
startup data deletion. The new route observation uses a read-only command that
has been present in the scoped controller ACL since v0.1.0; adopted routers do
not need an ACL refresh or re-adoption.

A clean binary/image rollback to v0.1.2 is schema-compatible. Retain the v0.1.3
data pair before rollback as normal operational practice.

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

Security and scope

• Collecting the installed route table is read-only. This release does not
  change routes, metrics, PPPoE, firewall, failover, or router configuration.
• The HTTP listener has no native TLS. The default Compose mapping is host
  loopback; use a trusted reverse proxy before remote access.
• Discovery, inspection, compatibility export, diagnostics, backup, and
  controller speed testing do not change routers. Adoption, Apply, RF scans,
  and optional capability installation remain separately acknowledged actions.
• No independent security audit or penetration test has been completed.

v0.1.2

oonfeeWRT v0.1.2

v0.1.2 is a patch release focused on hardware-inspection correctness and a
safe way to share compatibility evidence. It manages stock OpenWrt through
existing SSH/ubus interfaces; it is not firmware and installs no
controller-authored executable on a router.

Publication is complete only when the v0.1.2 tag workflow succeeds. Verify
downloaded archives with SHA256SUMS; the published OCI image also carries a
keyless signature, SBOM, and provenance attestation.

Highlights

• Fixed read-only inspection for single-interface, two-GMAC OpenWrt gateways.
  On a real Cudy M3000 v2 with Motorcomm YT8821, inspection now reports two
  physical radios, LAN eth1, WAN eth0, and no independent switch ports.
• Stopped counting multiple BSS interfaces as physical radios and prefer an AP
  interface when sampling a radio that also has a station interface.
• Added Export sanitized compatibility report after a successful read-only
  inspection. The versioned JSON contains bounded hardware, firmware, radio,
  port, feature-state, and supported-function evidence.
• The compatibility report excludes router and site identity, MAC and network
  addresses, credentials and secrets, network configuration, clients, live
  telemetry, timestamps, runtime radio/PHY and bridge-member identifiers, and
  free-text probe notes. Board-declared LAN/WAN labels remain because they are
  compatibility evidence. The report is downloaded locally; no additional
  router call, persistence, or upload occurs.
• Corrected VLAN omission guidance for a generic direct-interface LAN. The
  renderer no longer labels every such layout as legacy swconfig, and still
  leaves existing LAN/VLAN configuration untouched when it cannot safely
  create a tagged attachment.
• Added the comprehensive documentation portal and kept release/build checks
  aligned with the controller's bounded five-minute rollup retention.

Cudy and Filogic scope

The Cudy result is deliberately narrow. Read-only Inspect capabilities was
confirmed by the issue reporter on a Cudy M3000 v2 running OpenWrt 25.12.5,
target mediatek/filogic; issue #19
records that evidence.

This does not validate adoption/bootstrap, Apply/rollback/confirm, WLAN and
client operation, tagged VLAN management, polling/resource budgets, topology,
RF scans, speed tests, un-adoption, or other Filogic boards. Tagged VLAN
attachments on this single-interface LAN layout remain unsupported and are
omitted rather than guessed.

Upgrade and rollback

Back up the matching database/keyring pair before upgrading. v0.1.2 keeps
schema 19, so upgrading from v0.1.1 requires no schema migration and makes no
router change. A clean binary/image rollback to v0.1.1 is schema-compatible;
retain the v0.1.2 data pair before rollback as normal operational practice.

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

Security and scope

• Compatibility export is available only after authenticated, CSRF-protected
  read-only inspection and fails closed when evidence exceeds strict bounds.
• The HTTP listener has no native TLS. The default Compose mapping is host
  loopback; use a trusted reverse proxy before remote access.
• Discovery, inspection, compatibility export, diagnostics, backup, and
  controller speed testing do not change routers. Adoption, Apply, RF scans,
  and optional capability installation remain separately acknowledged actions.
• No independent security audit or penetration test has been completed.

v0.1.1

oonfeeWRT v0.1.1

v0.1.1 is a patch release focused on clearer operational evidence, bounded
controller storage, and a denser, more accessible interface. It manages stock
OpenWrt through existing SSH/ubus interfaces; it is not firmware and installs no
controller-authored executable on a router.

Publication is complete only when the v0.1.1 tag workflow succeeds. Verify
downloaded archives with SHA256SUMS; the published OCI image also carries a
keyless signature, SBOM, and provenance attestation.

Highlights

• Reworked Dashboard WAN health into truthful five-minute activity charts with
  explicit missing samples, route/probe provenance, a table view, and fixed
  polling backoff that no longer mistakes the expected ICMP probe duration for
  router load.
• Added compact topology and warning/error summaries, responsive page layouts,
  keyboard-accessible chart details, stronger contrast, and passive information
  popovers while keeping warnings, errors, authorization, and Apply safety
  details inline.
• Simplified controller-host speed testing: the Run action is the explicit
  plan-bound acknowledgement, exact impact/privacy details remain available in
  a nonmodal popover, and the three newest terminal attempts are retained
  separately from any active test.
• Condensed the repeated OpenWrt IPv6 router-advertisement condition without
  changing its warning severity or losing its raw evidence, bounded stored event
  size, and made event pruning independent of telemetry folding failures.
• Added desktop and narrow-width browser regression gates and clarified install,
  project-scope, AI-assistance, and validation documentation.

Upgrade and rollback

Back up the matching database/keyring pair before upgrading. v0.1.1 keeps schema
19, so upgrading from v0.1.0 requires no schema migration and makes no router
change. A clean binary/image rollback to v0.1.0 is schema-compatible; retain the
v0.1.1 data pair before rollback as normal operational practice.

On first v0.1.1 startup, completed or failed speed-test rows older than the
newest three are permanently removed. Back up the controller data first if that
history matters.

See INSTALL.md for verified download, container, backup, restore, and
signature commands.

Security and scope

• The HTTP listener has no native TLS. The default Compose mapping is host
  loopback; use a trusted reverse proxy before remote access.
• Discovery, inspection, diagnostics, backup, and controller speed testing do
  not change routers. Adoption, Apply, RF scans, and optional capability
  installation remain separately acknowledged actions.
• Gateway-run speed testing remains deferred. Loaded latency and jitter are
  unavailable for the controller-host method.
• No independent security audit or penetration test has been completed.

v0.1.0

oonfeeWRT v0.1.0

v0.1.0 is the first stable controller release. It manages stock OpenWrt over
existing SSH/ubus interfaces; it is not firmware and installs no
controller-authored executable on a router.

Publication is complete only when the v0.1.0 GitHub tag workflow succeeds.
Use the checksums, OCI signature, SBOM, and provenance attached to that release;
do not substitute artifacts built from another commit.

Highlights

• Polished, responsive Dashboard and navigation with accessible project-owned
  SVG icons, WAN health, compact topology, and summary-first notices.
• Explicit controller-host speed tests with a reviewed 15 MiB/30-second plan,
  cancellation, audit history, and no router management calls. Tests use
  Cloudflare's https://speed.cloudflare.com/__down and
  https://speed.cloudflare.com/__up endpoints; Cloudflare can observe the
  controller host's public IP and test requests.
• Schema-19 local accounts with owner, administrator, operator, and read-only
  roles, password step-up, session inventory, and revocation.
• Bounded, redacted diagnostics ZIPs containing stored controller and device
  evidence, model/firmware metadata, a manifest, and checksums.
• Encrypted portable .oowrtbak export plus previewed, plan-bound restore,
  pre-restore safety backup, session revocation, and persistent router-write
  suppression until owner review.
• Deterministic archives for Linux/macOS on amd64/arm64 and non-root scratch
  images for Linux amd64/arm64.

Upgrade and rollback

Back up the matching database/keyring pair before upgrading. The controller
migrates v0.1.0-rc.1 schema 17 to schema 19 on first start. A schema-19 data
directory cannot be opened by the older daemon; rollback requires stopping the
controller and restoring the pre-upgrade schema-17 database, matching keyring,
passphrase file, and prior image/binary together. No migration changes routers.

See INSTALL.md for verified download, container, backup, restore, and
signature commands.

Security and scope

• The HTTP listener has no native TLS. The default Compose mapping is host
  loopback; use a trusted reverse proxy before remote access.
• Discovery, inspection, diagnostics, backup, and controller speed testing do
  not change routers. Adoption, Apply, RF scans, and the optional official-feed
  LLDP package workflow remain separate acknowledged actions.
• Optional TOTP MFA and gateway-run speed testing are deferred. Loaded latency
  and jitter are unavailable for the controller test method.
• Hardware validation covers two OpenWrt 25.12.5 devices. Review
  FRESH-START-VALIDATION.md for exact evidence and remaining coverage gaps.

v0.1.0-rc.1

What's Changed

• Complete Phase 4 and harden the controller UI by @aiden0rchad in #1
• Update README for merged Phase 4 by @aiden0rchad in #2
• Transparent fresh-start, optional LLDP, and schema 17 by @aiden0rchad in #3
• build: automate v0.1.0 release candidates by @aiden0rchad in #4

New Contributors

• @aiden0rchad made their first contribution in #1

Full Changelog: https://github.com/aiden0rchad/oonfeeWRT/commits/v0.1.0-rc.1