User-defined SSID groups (configured on the WiFi Networks page and
stored in unifi.ssid_groups) now drive PPSK sibling propagation. The
previous same-SSID-name detection missed cases where two grouped
WLANs have *different* names — e.g. "VCS Guest" on 2.4 and "VCS
Guest 5G" on 5GHz manually grouped by the operator. Falls back to
same-name siblings when no group is configured.
Match-by-name fix: embedded PPSKs on this controller don't carry a
name field — the human "GUEST" label is the *network's* name, with
the entry referenced via networkconf_id. updateEmbeddedPpsk and
verifyEmbeddedPpsk now resolve name → networkconf_id first and match
on that, with entry-name and current-passphrase as fallbacks for
other controller variants.
After every rotation we re-fetch each affected WLAN and verify the
new passphrase is actually present on the named network. Failures
("mismatch" or "fetch_failed" on the primary, anything other than
"not_found" on a sibling) surface in the cron run details as failed
PPSKs so the operator sees what didn't propagate.
v1.10.4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The sibling-rotation path's "Embedded PPSK not found" error was being
surfaced to the operator as a failure, but it's not — it just means
the PPSK isn't mirrored on that band (GUEST was configured on one
band only, which is a perfectly valid setup). Logging this as a
sibling failure also poisoned the cron run status to "partial".
Now: "not found"-style errors from updateEmbeddedPpsk on a sibling
become info-level log entries and the loop continues. Other errors
(API failures, permissions, etc.) still surface as warnings/failures.
v1.10.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The sibling-update path on prod failed with "Embedded PPSK not found
by current passphrase" because the DB-stored x_passphrase on the
unedited band was stale — earlier manual edits (pre-1.8.1) only
touched one band, leaving the other band's row out of sync. When
rotation then tried to use that stale passphrase to find the entry,
no match.
updateEmbeddedPpsk now takes an optional $name parameter and tries it
first. PPSK names within a WLAN are unique, so name-matching survives
any passphrase drift caused by historical out-of-band edits.
Passphrase matching stays as a fallback for callers that don't have
a name (none currently — both rotation and the manual modal pass it).
v1.9.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three bugs reported from prod after a PPSK rotation:
1. unifi.password_rotation.last_password was only saved after a
whole-SSID rotation. PPSK-only setups (the typical guest-WiFi case)
ran a successful rotation but the setting stayed empty, so the
Settings → Tasks UI never showed the current password and the
/api/unifi/wifi/current-password endpoint returned 404
"no rotated password recorded yet". The PPSK loop now writes
last_password on every successful PPSK rotation.
2. When an SSID is "banded" (band-steering disabled), UniFi splits it
into one wlanconf per band — 2.4GHz and 5GHz each get their own _id
and their own embedded PPSK array. Rotating the PPSK on one band
left the other band with the old password. New
UnifiApiClient::getWlanSiblings($wlanId) finds all wlanconfs that
share an SSID name; both rotation and the manual modal edit now
call updateEmbeddedPpsk on each sibling and update the matching
UnifiPpsk DB rows.
3. The manual WiFi modal edit had the same band-blindness as #2 —
editing the GUEST PPSK on the 2.4GHz half left the 5GHz half stale.
WifiController::ppskUpdate now walks siblings the same way.
v1.8.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* RotatePasswords now stores the active wordlist entry as
unifi.password_rotation.last_password whenever a whole-SSID rotation
succeeds. Per-PPSK rotation continues to store passwords on each
PPSK row as before.
* Settings → Tasks tab surfaces the current password in bold beneath
the wordlist textarea so operators can quickly check what's live.
* New JSON endpoint GET /api/unifi/wifi/current-password returns
{"password": "...", "rotated_at": "..."}. Protected by a token stored
in unifi.api_token — pass as Authorization: Bearer <token> or
?token=<token>. 401 on bad/missing token, 503 if no token is
configured, 404 if no rotation has happened yet.
* Settings page lets super-admins Generate / Regenerate / Clear the
token. Generated tokens are 48-char hex from bin2hex(random_bytes(24)).
* The endpoint lives outside the web/auth middleware so external
signage / kiosks can hit it without a session cookie.
v1.6.2.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Embedded PPSKs live inside the parent WLAN's private_preshared_keys
array — they have no controller-side _id and the synthetic emb_<hash>
we generate locally isn't a real REST id. Hitting /rest/ppsk/emb_xxx
returns HTTP 400/503, which is what the GUEST PPSK rotation was
failing on at the scheduled 3pm run.
* New UnifiApiClient::updateEmbeddedPpsk($wlanId, $oldPass, $newPass):
GETs /rest/wlanconf/{wlanId}, finds the matching entry in
private_preshared_keys by current passphrase, swaps the value while
preserving whichever field name the controller uses (x_passphrase /
password / passphrase), and PUTs the whole WLAN object back.
* RotatePasswords detects emb_-prefixed unifi_ids and routes through
the embedded path. The synthetic id is rederived from the new
passphrase so the DB row stays addressable.
* WifiController::ppskUpdate (manual modal save) does the same — this
is why manual edits sometimes appeared to succeed but the controller
side actually rejected them.
Verified live against the GUEST PPSK on 10.81.0.1.
v1.5.5.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Password rotation was short-circuiting any run that had no whole-SSID
wlan_ids configured, even if there were PPSKs with rotate_password=true
in the database. The PPSK rotation block lived after the early-return,
so per-PPSK rotation never fired. Now we only skip when there's nothing
at all to rotate (neither wlan_ids nor PPSK opt-ins).
* Webhook routes moved from /app/network/webhooks to
/app/network/settings/webhooks so the URL reflects that this is a
settings tab. Route names unchanged.
v1.5.3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds unifi_cron_runs table (one row per scheduled-task execution) and
UnifiCronRun::record() wrapper that captures start/finish/status and
exceptions. The three scheduled commands now write through it:
- reboot-all-aps → rebooted/failed AP names per run
- rotate-passwords → rotated SSIDs + PPSKs, failures (when actually
rotating; the "is it due" early-return is silent
so we don't flood the log with no-op rows every
minute)
- sync-ppsk-schedules → enabled/disabled PPSKs (silent when there's
no work)
UnifiCronLogsController returns the most-recent 200 runs as JSON,
filterable by command + status. Behind permission:unifi.settings; no
super-admin required — read-only history is fine for any operator
who can see settings.
v1.5.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drops unifi.timezone from the settings form (now lives in
Admin → Settings on the shell). Schedulers (PPSK sync, password
rotation) now read \App\Support\Timezone::current() — same fallback
chain as the rest of the platform.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add password rotation: RotatePasswords console command + migration + service updates
- Add PPSK management: UnifiPpsk model, migration, SyncPpskSchedules console
- Add VLAN groups and AP groups: VlanGroupController, ApGroupController, model, migration
- Add RebootAllAps console command
- Add in_alert column to device states
- Wire new features through service provider, routes, and existing controllers/services
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
