v2.0.2 Release Changes#981
Merged
Merged
Conversation
The agent status line rendered the raw MinVer informational version (v2.0.1+ed2714ca72415f2d08512e643c); strip the +hash for display the way the footer does, keeping prerelease identifiers. The full version stays stored on SiteAgents.LastVersion for diagnostics, and IsOlderThan already ignored build metadata, so only the rendering changes.
… :root color-scheme
… configured device host
…matching the ONT providers
…unnel-proxy endpoint
…l the configured host
* Add simplified Client Dashboard view for Tailscale/Teleport/VPN clients VPN-sourced viewers (Tailscale CGNAT, Teleport, remote-user VPN) never appear in the UniFi client list, so the dashboard previously showed Device Not Found. They now get a simplified view: the same VPN logo used in speed-test traces, client name + IP, the two speed-test buttons, results, and a working map. - Extract shared VPN classifier (ClassifyVpnClient) as the single source of truth for hop creation and dashboard identity - Shared VpnIcon component reused by the trace and the identity bar - IP-keyed speed-result lookup (VPN clients have no MAC) - Skip live polling / GPS for VPN clients; Speed tab only - Pre-select the map External layer for VPN clients - Clearer Device Not Found copy on the default site based on console reachability, with the detected address surfaced Default-site only; managed-site behavior is untouched. * VPN client dashboard: drop the sole tab bar, rename to 'X Client' - Hide the tab bar entirely for VPN clients (a single Speed tab looked odd); keep the time-range filter - Name VPN clients 'Tailscale Client' / 'Teleport Client' / 'VPN Client' - Drop the now-redundant name from row 2 (shown in the identity name) * VPN client dashboard: refresh speed results live VPN clients had no poll timer, so new speed tests only appeared after a manual page refresh. Add a lightweight timer that reloads the Speed tab results/charts on the same ~5s cadence as Wi-Fi clients, without the signal poll or L2 trace (neither of which exists for VPN clients). * Client Dashboard: auto-resolve managed-site identity on cold agent connect On a managed site, the on-site agent's tunnel may still be coming up when the dashboard first loads. The resolver then reports no agent target, so the whoami identity probe was skipped and the viewer dropped to the device picker - only a full page refresh (a warm connection) resolved identity. Poll the resolver for a bounded window (~20s) so identity resolves automatically once the agent's tunnel comes online, keeping the loading skeleton up meanwhile. A reachable-but-unusable agent (e.g. untrusted certificate) still falls straight to the picker. * Managed-site identity: background-retry on cold agent/console connect Replace the single whoami probe (and the earlier skeleton-blocking retry loop) with: one immediate attempt, then show the picker right away AND keep probing in the background (~1s, up to 30s), auto-loading the moment the agent's tunnel and console are live. The viewer is never stranded on the picker waiting for a manual refresh, and can still pick a device to stop the retry early. Also close the site-switcher dropdown when the already-active site is clicked - done in site-context.js after the modified-click guard, so ctrl/cmd/shift/middle new-tab behavior is untouched (no Blazor @OnClick on the switch anchors). * Fix intermittent 'Device Not Found' flash on managed-site identity resolve Clearing _awaitingSiteIdentity before the async whoami attempt (and before the picker's client list finished loading) left a window where a poll-timer re-render showed the generic 'Device Not Found' card instead of the loading skeleton - intermittently, and most visibly when switching to a site you're not physically at (the whoami probe there runs to its full timeout). Keep the skeleton up until a terminal state: clear the flag only on success, or atomically with _showClientPicker when the picker becomes visible. Managed-site only; the default/single-site path never enters this code. * Speed test map: auto-fit when new results arrive The map only re-fit when new markers happened to land fully off-screen; a new result appearing outside the current view while other markers were visible was never brought into view. Fit on data change (new result, or background enrichment reclassifying one), gated by userHasZoomed so a manual pan/zoom is still respected - the same guard the time slider and layer toggles already use. Applies to both the VPN client map and the main LAN speed test map. * Speed test map: re-enable auto-fit on time-filter change * PWA: break out of a wedged reconnect spinner via a health-gated reload * Flaky targets: surface the advisory on ISP Health and clear it once addressed * Sites page: clicking the current site opens its dashboard instead of dead-clicking
…lash the setup prompt
…d flaky targets (#983) * Pause off-path transit ASNs on discovery review, incl. dangling hand-added targets A transit ASN with auto-discovered evidence that goes absent from 3 consecutive discovery runs is surfaced in the Upstream Discovery review (pre-unchecked); committing pauses every enabled Transit target in the ASN - auto and hand-added alike. Targets are paused, never deleted. - Removal eligibility no longer requires the auto target to be enabled (a flaky auto target the user paused must still catch its dangling hand-added siblings), but does require >=1 enabled target in the ASN so a fully-paused ASN retires instead of pinning the daily recheck. - The absence counters now advance once per completed discovery run, manual and scheduled alike, via a shared post-run evaluation staged on the tracer state; the scheduler reads the staged outcome. - Commit clears surfaced ASNs miss counters so "Keep" re-nags only after fresh 3-run evidence; non-actionable confirmations (access and path tiers) prune so the recheck cadence recovers to 7 days. * Surface off-path transit ASNs being tracked toward removal in the review Before an absent transit ASN reaches the removal-confirm threshold, show a read-only "Tracking possible removals" section in the Upstream Discovery review: which ASN went off-path, how many consecutive runs it has been absent, how many more are needed to confirm, and how many targets would be affected. Makes the detection visible instead of silent until it suddenly confirms. Staged by the same shared post-run evaluation as the confirmed-removal set, so it stays accurate for manual and scheduled runs alike. Pending and confirmed are mutually exclusive per ASN; informational only (no checkbox, no commit action). RunsRemaining is run-count based for now - revisit the copy to express remaining time once the per-ASN time gate lands. * Rename review column "Keep" to "Keep Active" Clearer that leaving it checked keeps the target monitoring, rather than "keeping" the row in some list. Widen the column so the header fits. * Time-gate absent-ASN miss increments to once per 6h An off-path ASN's consecutive-miss counter now advances at most once per 6h per ASN, so absence has to persist across real time rather than across however many runs happen to fire. Three gated increments => a ~12h+ off-path floor before a removal confirms - long enough to ride out maintenance drains, and immune to rapid manual re-traces stacking the counter. - Counter store carries a per-ASN last-increment timestamp ({"c":n,"t":iso}); legacy bare-int values load as immediately gate-eligible, no migration. - A gated run holds the count and timestamp; a confirmed ASN stays a removal candidate even when gated (a tight recheck can't un-confirm it). - PendingRecheckInterval dropped 24h -> 6h to match the gate, so scheduled rechecks land just past it and real removals confirm in ~12-18h. - EvaluateChange takes nowUtc + gate explicitly so it stays pure/testable. * Widen "Keep Active" review column to 115px * Prompt to reset upstream monitoring when discovery finds the access ISP changed * Flaky targets: stop flagging a target once its recent bins are stable again * Flaky targets: fast recovery for hard-down outage episodes * Hard-down fast path: judge by median over-threshold bin so boundary bins don't defeat it
…ccess ISP on unannounced first miles (#984) (#985) * Upstream path discovery: stop crowning a probe destination as the access ISP (#984) The access-ISP pick was 'first hop with a resolvable ASN across the merged pool'. Bell Canada's PPPoE first mile is RFC1918 plus public /16s Bell deliberately does not announce in BGP (142.124/142.125), so every early hop resolved to null and the first attributable hop was Cloudflare's own edge on the 1.1.1.1 trace - Cloudflare became the 'access ISP' and Bell fell through to the transit list. Replaced with two signals (DetermineAccessAsn): - The WAN IP's own ASN (the ISP's customer allocation) wins when resolvable and corroborated by any hop, or when no hop is attributable at all. - Otherwise per-trace voting: each trace nominates its first attributed hop, skipping destination ASNs (a destination's edge only appears on traces toward itself; the real access ISP fronts essentially every trace). Also positionally attribute the unannounced first mile: hops before the first access-ASN hop on their own trace that sit in unattributed public or CGNAT space are the ISP's aggregation layer and now join the access hop pool (RFC1918 prefix hops stay excluded - bridged CPE / double-NAT risk). Destination ASN/org resolution moved to a shared once-per-run step so the access and transit passes use the same sets. * WAN L2 neighbor: pick the routed default gateway, not the best-scoring ARP entry On a shared WAN subnet (metro Ethernet, two sites on one carrier segment) 'ip neigh show dev <wan>' also lists unrelated same-subnet hosts, and the heuristic scoring (subnet > address class > freshness) can rank a peer - e.g. another site's gateway, REACHABLE while the real gateway is STALE - above the true next hop. Read the WAN's default gateway from 'ip route show table all' (UniFi policy routing keeps each WAN's default in its own table; matching on the dev finds it regardless of table number) and return that IP's neighbor entry outright, still taking the MAC from ip neigh so the OUI/first-mile-device labeling is unchanged. Scoring remains the fallback when no routed gateway is found (on-link/PPPoE defaults have no via and no MAC). * First-mile labeling honors the saved per-WAN access technology Pre-existing (surfaced testing #984's fixes): re-running discovery suggested 'YELCOT cisco-access' on an install with GPON saved - the L2 hop label and role ignored the stored technology until the dropdown was toggled. Two cooperating causes: - LoadPersistedAccessTechnologyAsync took the most-recent WanDiscoveryContexts row regardless of WAN or whether it held a technology, so on multi-WAN installs a fresher row for another WAN returned Unknown. It also never fell back to the legacy MonitoringSettings.AccessTechnology. Now: the traced WAN's own row first (re-checked in RunAsync once detection resolves the WAN), then any row with a known technology by recency, then the legacy settings column. - Commit wrote State.AccessTechnology unconditionally, so a run that started with Unknown wiped the user's saved value (breaking the 'discovery only proposes' contract documented on SetAccessTechnologyAsync). Unknown is no longer written over a saved technology.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Placeholder roll-up for the next patch release. More changes will be added before it ships.
Client Performance
LAN Speed Test
Monitoring
+buildsuffix, matching the footer.Reconnecting
Multi-Site
Settings