9 Commits

Include renames

Author	SHA1	Message	Date
2GT-RichandClaude Opus 5	1a4b635052	fix(firmware): halt-on-failure stopped waiting for the wave to finish (v0.24.5-beta) ... A regression I introduced in v0.24.3, and described inaccurately in its own commit message. Adding concurrency moved the halt check to the end of a wave. I wrote that "at the default of 1 those are the same moment". That is only true of a wave holding one device. With several devices in one wave and the default sequential setting, the old code stopped the moment one failed; mine went on to attempt every remaining device in that wave first. Anyone relying on halt-on-failure with a wide wave 1 got a wider blast radius than before, without changing a setting. Halting now stops further devices from *starting* as soon as a failure is known, whatever the concurrency. Devices already in flight are allowed to finish, because interrupting one mid-write is how you brick it. At concurrency 1 that is precisely the previous behaviour. Above 1, only the devices genuinely running side by side can carry a bad build -- which is the unavoidable part of the trade in #135, rather than a cost imposed on rollouts that never asked for concurrency. The firmware documentation said the same wrong thing and is corrected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-08 08:54:51 -07:00
2GT-RichandClaude Opus 5	6c3d2aaa35	docs: firmware rollouts and backups ... Neither area had a page, and both changed materially in v0.24.2/v0.24.3. The firmware page records why the pipeline downloads and verifies before rebooting, and what raising "at once" actually costs: halting becomes less precise, devices reboot together, and the upstream warning is conservative enough that its absence is not proof of safety. The backups page leads with the fact that a backup is /export text rather than a binary blob, since that is what makes preview and diff possible and what limits what a restore can do. It also states plainly that a backup and its Config History snapshot are one artifact, so deleting one removes the other's rollback. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 21:42:55 -07:00
2GT-RichandClaude Opus 5	7b994ad935	feat(sites): one install, many networks (v0.24.0-beta) ... Closes #130. Multi-site, not multi-tenancy: a site is a named collection of devices whose clients, events, topology and dashboards are viewed separately. Sites separate what you see, not who you are — the admin/manage/read-only roles are unchanged and every user sees every site. Per-site permissions would have multiplied the work for a need nobody stated. Two measurements decided the design. Every device-derived table hangs off devices(id) — 25 of 50 tables, 35 foreign keys — so a single site_id column on devices scopes clients, events, topology, backups and the rest transitively. No other table needed one. The frontend has 162 useQuery call sites across 57 files. Threading a site through each would be a large change that leaves a permanent trap: every future query another chance to forget. The site is injected in the existing axios interceptor instead, beside the auth token, so a new query is scoped by default. Only 23 collection routes needed filtering; the 131 per-device routes are already scoped by their device. Existing installs are untouched. Migration creates one "Default Site", adopts every device into it, and a single-site install never meets the concept. An absent X-Site-Id header means unscoped, so existing API tokens and scripts behave exactly as before. Polling stays fleet-wide. Sites are a view over data already gathered, not a change to how it is gathered — a device does not stop being monitored because you are looking elsewhere. Rogue-AP detection scopes the scans but keeps the "these are ours" BSSID set fleet-wide, or your own AP in another site reads as an evil twin. Bulk actions do obey the selector: an operation that silently spanned two customers is the blast radius the wave guards exist to contain. Four rounds of defects came out of testing the UI rather than the API, and the first is the one worth recording. Switching sites called queryClient.clear(), which empties the cache and reviews as correct. It isn't: clear() destroys each query but a *mounted* observer keeps its own reference and last result, so every rendered page went on showing the previous site's data. The QueryClient is now keyed on the site, which remounts the tree against an empty cache. Three tests pin the old behaviour down so the shortcut cannot return. The others: an unscoped fallback path behind the Connected Clients chart; Config Health, TX retries and the activity feed reading fleet-wide; and site_id added to the device list query but none of the other four that build a device payload, so the Site field could not read its own value and appeared to reject every change while the writes were landing. That last one is now structural — DEVICE_BASE_COLUMNS is shared by all five, with a test that fails when a device payload is hand-rolled, and which found two further instances while being written. Frontend tests were never run by CI despite vitest being configured and six suites existing; they now run in both the workflow and ci-preflight. Verified against a live four-device fleet: the migration left every figure identical, an empty site returns zero from every read endpoint, moving a device carries its history with it, and deleting a site with devices is refused. Minor bump rather than patch: sites change the shape of the product rather than adding to it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 12:02:00 -07:00
2GT-RichandClaude Opus 5	273a0da737	fix(deploy): restore NetFlow to the published compose file, and generate it (v0.23.34-beta) ... Closes #121. The Quick Deploy file was missing NETFLOW_BIND_PORT and the 2055/udp mapping, so the collector bound inside the container and nothing reached it. NetFlow did nothing, silently, with an empty traffic page and no error — for everyone following the path the README tells new users to take. The report was accurate and understated. docker-compose.ghcr.yml had drifted for seven weeks, and three closed issues had never reached it: * NETFLOW_BIND_PORT and the UDP port — as reported * all five POLLER_* tunables — #114, whose fix was "pass the tunables through" * the Redis memory ceiling and eviction policy — #116 * TZ on the postgres service, which nobody had noticed at all The middle one is the uncomfortable part. Four days ago #114 was closed by forwarding poller settings that were documented but inert, with a comment saying setting them "did precisely nothing". On Quick Deploy that remained true, because one compose file was fixed and the other was not — including the advice given to that reporter about which knob to turn. So patching the four gaps would have been treating the symptom. The two files describe the same system and differ only in where images come from; maintaining both by hand meant remembering every change twice, and the one forgotten was always the file no maintainer runs. docker-compose.ghcr.yml is now generated from docker-compose.yml by scripts/generate-ghcr-compose.mjs, which performs the two build-to-image swaps and nothing else. Substitution is textual rather than parse-and-reserialise so comments survive — the reasoning about Redis eviction is worth more than the two lines it explains. The file stays committed and browsable, because the README tells people to curl it directly. A --check mode runs as the first preflight gate and as its own CI job, both of which fail when the committed file does not match what the generator produces. Verified by deleting the NetFlow line and watching the guard reject it, with the reason and the fix in the failure message. Reported by @mamb1329, on their first issue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-06 13:08:56 -07:00
2GT-RichandClaude Opus 5	6c5b8ac21a	feat(lte): time-on-band and time-on-cell statistics (v0.23.33-beta) ... Closes #120. The Tower and band changes panel listed every handover, newest first, growing without bound. On a link that hands over several times a day it reads as a wall of near-identical rows — it answers what happened, but not what the pattern is, which is the question an operator actually has. Dwell totals now sit above it: how long the modem has spent on each band and on each cell, over 24 hours, 7 days or 30 days, ordered by time spent so the answer is the first row rather than something to be worked out. Visit counts sit alongside, because six brief stays and one long one are different situations that share a total. No new collection. History is already written on every change, so dwell is the interval between consecutive events — the same reconstruction used for WiFi roaming sessions. Three decisions worth recording. **The state in force when the window opened is included.** Without it, a link that changed once yesterday would report a few minutes of dwell across seven days, having silently dropped everything before the first change in range. The last event *before* the window is fetched specifically to anchor that first stretch. **Aggregated carriers each count for the whole stretch.** A period on B1 and B3 together credits both with the full duration, so band shares describe how much of the window each band was in use rather than dividing it between them. Totals can exceed 100%, which is the honest description of carrier aggregation rather than a rounding artefact. **Absence is reported as absence.** A segment whose cell was never reported is excluded rather than attributed to "unknown", a device with no history reads as "no changes recorded" rather than an empty panel, and a window longer than our records says so instead of implying the quiet period was real. Logic lives in utils/lteDwell.ts with 17 tests. Verified end to end against seeded history matching the reporter's own pattern: a 24-hour window covered exactly 24 hours, B3 correctly showed 19 of them against a five-hour stretch without it, cell totals summed to the window, and a 30-day request over 9 days of records reported itself truncated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-06 09:30:07 -07:00
2GT-RichandClaude Opus 5	98a72e1f7a	docs: versioned documentation site, and the four pages that were missing (v0.23.28-beta) ... Closes #112. Source stays `docs/*.md`, rendered by MkDocs-Material and published to GitHub Pages by Actions. Same repository on purpose: documentation drifts, and co-location is the only thing that reliably prevents it — the pull request that changes behaviour changes the description, and review sees both. A separate repo would double the ceremony and guarantee divergence. The markdown remains readable when browsing the repository, so the site renders those files rather than replacing them. **Versioned from the start**, using mike. Images are published to GHCR and this project ships betas most days, so readers are routinely running something other than the newest build; a single "latest" would confidently describe a release they do not have. Versions follow the product rather than the docs, so the site and the running image carry the same number. **Content came first, and it had to.** The docs were eleven days and sixteen releases stale — SSH keys, bulk commands, the data-cap SMS, poller health and the timezone setting appeared in exactly zero files between them. Publishing that would have given documentation missing five of the most consequential features a polished, authoritative home, and a well-presented wrong answer is worse than an obviously rough one. Four pages now cover them: - cellular.md — signal grading, carrier aggregation, the uplink anchor, observed bands, and the data-cap SMS including why it fires early and how to calibrate the margin - ssh-keys.md — leading with what installing a key costs, because RouterOS disables password SSH for that user and the database becomes load-bearing - commands.md — why waves exist, and why reading output matters when RouterOS reports failure in text rather than an exit code - scaling.md — headroom, why it is insufficient on its own, and every tunable Pull requests build the site with `--strict`, which turns warnings into errors. That is the point of running it there at all, and it earned itself immediately: the first build failed on two links to the project README, which sits outside the docs tree. They are absolute now, so they resolve both in the rendered site and when reading the markdown on GitHub. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-02 18:42:40 -07:00
2GT-RichandClaude Opus 5	57d650c159	feat(wireless): reconstruct per-client roaming history from AP logs (v0.23.11-beta) ... Closes #105. RouterOS narrates the whole life of an association in its log — association, every band or AP change, and the disconnect — each line carrying the signal at that moment. Nothing else in the platform can see any of it: roaming happens between polls, so a poll only ever observes where a client ended up, never that it moved. Sessions are now rebuilt from those lines and shown on the client detail page: the path across radios, signal at each step, duration, and RouterOS's own disconnect reason. Sessions averaging six or more roams an hour are flagged, since a client bouncing between radios is usually a roaming-threshold problem rather than a faulty client. No new collection and no new storage. It reads the events already gathered, so it works retroactively over whatever log history exists. Two things came out of testing against real logs rather than the samples in the issue, and both were wrong in ways the samples could not have shown: Ordering. RouterOS log timestamps are second-granular, so a reassociation emits its disconnect and reconnect inside the same logged second, and collection assigns sub-second values in whichever order they were read — observed on a live AP as both `.849/.849` and `.096/.097` for the same kind of pair. Sorting on the raw timestamp attached the disconnect to the session the connect had just opened, so every reassociation reconstructed as a 0-second session while the real one disappeared. On one IoT client that was 255 phantom sessions out of 422. Events are now ordered by whole second and ties broken by meaning: a disconnect closes what came before, a connect opens what comes after. The same client now shows its real behaviour — 900s, 840s and 930s sessions, reassociating every 15 minutes. Signal sanity. Real logs contain `signal strength 91`. dBm is negative, so a positive reading is not a measurement; recording it would draw a client with an impossibly perfect signal. Treated as unknown. 21 tests, including the full ping-pong trace quoted in the issue — which the reconstruction correctly identifies as flapping — plus both timestamp-collision shapes seen in production. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 21:27:14 -07:00
2GT-RichandClaude Opus 5	5071e1f512	chore(dev): seedable CAPsMAN fixture so managed-wireless paths can be tested (v0.23.8-beta) ... Two bugs shipped in the last three releases because CAPsMAN code was written and "verified" against a fleet that contains no CAPsMAN. Neither was reachable by unit tests, because both lived in SQL: a join that could never match, and a WHERE clause that filtered out every managed radio before the analysis ran. Both were found by the reporter, in production, after release. The fix is not another test of the pure functions — those were already right. It is to stop the local environment from being unrepresentative. scripts/seed-capsman-fixture.sql builds a deployment shaped like a real one: - the controller is a ROUTER with no radios of its own, so anything keyed on device_type = 'wireless_ap' misses it - CAP interfaces carry NULL frequency, SSID and band, because the controller owns the configuration — the exact condition that removed them from Channel Usage - the controller mirrors every CAP interface locally, so a CAP's radio MAC legitimately appears on two devices — the condition behind the misattribution - channels exist only as "<freq>/<phy>/<control-positions>", never a plain number - the radios are arranged to produce one partial overlap and one co-channel pair, so interference classification has something real to get wrong Running it against v0.23.7 confirms the fix shipped blind two commits ago actually works: six managed radios now group under the controller, the controller appears in the location selector, the standalone group holds only the genuinely standalone AP, 5680/ax/eCee/D resolves to 80 MHz, client counts come from the controller where the CAP rows read zero, and the controller's mirror interfaces do not double-count. Documented in docs/architecture.md, including the point that when a report arrives with device output attached, that output is the most valuable thing in it and belongs in the fixture. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 20:21:19 -07:00
2GT-RichandClaude Opus 5	e10f7ba568	docs: split reference material into docs/, keeping the README a shop window (v0.23.4-beta) ... Documentation only — no functional change. The README was carrying two jobs for two different readers. Its Reference section was the single largest block at 154 lines, and nobody deciding whether to try the project reads an InfluxDB environment variable table — while the people who need it were scrolling past the pitch to reach it. Split along that seam: anything you would read before installing stays in the README, anything you would read after installing moves to docs/. README.md 430 lines sell, prove, install, feature overview docs/change-guard.md 193 safety system, settings, guard states docs/architecture.md 116 data stores, polling model, module layout docs/capsman.md 84 role model, radio matching, current limits docs/alerting.md 81 rules, channels, webhooks, maintenance windows docs/api.md 77 scoped tokens, preflight, scripting docs/configuration.md 76 environment, secrets, rotation, TLS docs/sso-oidc.md 71 identity provider setup and behaviour docs/README.md 20 index In-repo rather than a documentation site, deliberately. A change to Change Guard's semantics can edit its documentation in the same commit as the code — which, given how often that behaviour has been refined recently, is the property that actually matters. A static site generator can point at docs/ later without moving a file. The Change Guard pitch stays on the front page: the problem framing, the verified recovery timeline and the quoted prediction warning are what make someone care, and a reference page is the wrong home for them. Three sections are new rather than relocated, written because the split exposed the gaps: - architecture.md did not exist. It now records why there are three data stores, the polling cadences, and which modules are pure functions over a snapshot and why. - Scoped API tokens shipped without usage documentation. api.md shows preflighting a change from a script and reading the guard block afterwards. - change-guard.md records why ip-on-bridge-port is informational rather than critical on RouterOS 7 — reasoning that previously existed only in a commit message. Every internal anchor and cross-file link verified to resolve, including anchors into other documents. No content dropped, checked by keyword comparison against the previous single file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 12:26:18 -07:00