A device shows perfectly online in the tenant admin UI — config channel green, device management page clean — and Portal authentication still fails for every user behind it. The device management page reads the config channel, not the one that actually authenticates users. This is how to prove that the authentication channel itself has quietly gone offline while everything else still reports healthy, using the device channel log and, when that's not conclusive, a direct redis-cli cache count comparison over an SSH session.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A controller doesn't track one online/offline state per device — it tracks several, and the admin UI only shows you one of them.
A device's connection to a cloud-managed campus controller isn't a single online/offline flag. It's split into separate channels — configuration, performance, authentication, and (in fabric deployments) an IP Group channel — each with its own independent state. The device management page most engineers check first reads the configuration channel. If that channel is up, the device shows green, and it's tempting to rule the device out entirely. But if the authentication channel specifically has gone stale while the config channel stayed up, Portal logins keep failing and nothing in the obvious place tells you why.
What follows is the triage that scopes this kind of failure correctly, the device-channel-log method that catches most cases, the root-SSH-plus-redis-cli cache comparison for the cases that method doesn't resolve, and the remediation choice between restarting one AP and restarting the whole authentication service.
Four causes produce the same "Portal keeps failing" ticket — this is where the fake-offline authentication channel sits among them, and how you get from symptom to proof.
Diagram labels are kept in English for engineering clarity.
The three surrounding causes each announce themselves clearly — a cloud service outage is site-wide, a network fault shows in the browser URL and access logs, a compatibility issue is scoped to one device type. Fake offline is the quiet one: everything upstream of it looks fine.
Scope it first, then prove it two different ways, then pick the right-sized fix.
Before chasing the authentication channel specifically, scope the failure using the same three checks that apply to any authentication complaint.
This is the fast path — it directly answers whether the authentication channel specifically was ever recorded as offline.
When the channel log isn't conclusive on its own, this comparison settles it — the two counts either match or they don't.
/opt/redis/bin/redis-cli -h 10.173.10.11 -p 26542 -cipherdir /opt/redis/etc/cipher -a campuscachedb@ossdbuser@Example@123
hgetall "ac_campus_portalserver_devtonode"
exitThe size of the count mismatch decides which lever to pull — restarting individual APs doesn't scale to a platform-wide drift.
https://<management-plane-ip>:18102
// log in with the admin account, open the product's Services tab
// search for the target service, select it, click Stop, wait for status to change, then click StartThe mechanism above is straightforward once you see it — these are the ways it actually trips engineers up.
SYMPTOMThe device management page shows the device green and healthy, but users behind it can't complete Portal authentication.
CAUSEA controller tracks configuration, performance, authentication, and (in fabric scenarios) IP Group state as separate channels. The device management page reads the configuration channel specifically. A device can show fully online there while its authentication channel — the one that actually matters for Portal logins — is stale.
FIXOnce the config channel checks out clean and authentication is still failing, stop looking at the device management page and go straight to the device channel log for that specific device's authentication-channel history.
SYMPTOMNothing in the admin UI itself flags a problem — no alarm, no red status, no obvious discrepancy anywhere on screen.
CAUSEThe UI doesn't cross-check the platform's device list against the authentication cache's own record count — the two numbers can drift apart silently, and nothing surfaces that drift unless someone counts both sides independently and compares.
FIXTreat the admin-visible online count and the redis cache online count as two independent numbers that must be actively compared — don't assume the UI would tell you if they'd diverged.
SYMPTOMRunning a plain redis-cli command against the controller's cache returns an authentication error or nothing at all, making it look like the cache service itself is down.
CAUSEThis controller's redis instance runs on a non-default port with TLS enabled through a specific cipher directory and a service-account password — none of which a bare redis-cli invocation supplies. The command has to carry -h, -p, -cipherdir and -a exactly, or it fails before it ever reaches the actual cache query.
FIXAlways invoke it with the full set of flags — host, port, cipher directory and service-account credential — as a single command, not built up interactively, and exit the root session as soon as the query is done.
/opt/redis/bin/redis-cli -h 10.173.10.11 -p 26542 -cipherdir /opt/redis/etc/cipher -a campuscachedb@ossdbuser@Example@123
hgetall "ac_campus_portalserver_devtonode"SYMPTOMRestarting the one affected AP fixes that device, but the same failure keeps recurring elsewhere across the tenant.
CAUSEWhen the count mismatch is large, it isn't a handful of stale entries — it's the authentication service itself that needs to re-establish connections platform-wide. Restarting APs one at a time treats a service-level problem as a device-level one, and never catches up.
FIXCompare the size of the count mismatch before choosing a remedy: a small, isolated gap gets an AP restart; a large, spread-out gap gets a CampusAAAAuthService restart instead.
SYMPTOMA separate ticket describes authentication failures on wired ports, with error codes and a RADIUS chain that don't match anything described here.
CAUSEThe authentication channel and its fake-offline failure mode are specific to a controller acting as a Portal server over the Haca protocol. Wired 802.1X/NAC authentication runs an entirely separate client-access device-RADIUS chain with its own error codes and its own CLI, and has nothing to do with this cache-versus-UI mismatch.
FIXDon't reach for a redis-cli cache comparison on a wired authentication ticket — work the 802.1X/NAC chain on its own terms instead.
Pulled straight from the field — the ones worth having an answer ready for.
The configuration channel is what the controller uses to push configuration to a device, and it's also what the device management page's status reflects. The performance channel is how the controller receives CPU, memory and terminal-count reporting — its loss affects monitoring visibility, not forwarding. The authentication channel exists specifically when the controller acts as a Portal server over the Haca protocol; when it's offline, Portal authentication for that device fails even though forwarding and management both look fine.
A genuinely offline device shows offline everywhere — configuration channel, performance channel, device management page, all of it. A fake-offline authentication channel is narrower: the device is reachable, its configuration channel is up, and the admin UI shows it healthy, but its authentication-channel cache entry never got updated after some earlier disconnect-reconnect cycle, so Portal logins routed through it keep failing.
A read-only command like hgetall against this specific key is a query, not a write, and it's the documented method for this exact check. The precautions that matter are procedural: use the root account only for the duration of the query, supply the full connection flags exactly as documented, and exit the session immediately afterward rather than leaving a root shell open.
Look at how large the gap is. If it's a small difference — one device or a handful — restarting that AP to force it to rebuild its session is the proportionate fix. If the gap is large, the underlying authentication service itself needs restarting so every device reconnects at once; restarting devices individually at that scale just won't catch up.
No. This fake-offline condition is specific to the authentication channel a controller maintains when acting as a Portal server over Haca. Wired 802.1X/NAC authentication runs a completely separate client-access device-RADIUS chain with its own error codes and CLI, and isn't affected by this particular cache-versus-UI mismatch at all.
This note is built around a specific cloud-managed campus controller's channel model, its Device Channel Log, and the root-plus-redis-cli cache comparison documented for it, plus the operating guidance behind it. It covers the Portal/Haca authentication-channel fake-offline case specifically — it doesn't cover configuration-channel or performance-channel failures, License-related offline states, or wired 802.1X/NAC authentication, all of which follow their own separate diagnostic paths.
Tell us the admin-visible online count versus what the authentication cache shows, and we'll help you read the gap.