Before you leave site

Ten minutes that saves a return visit.

The checks

Once the controller is registered and its redirect/RADIUS/walled-garden settings are in place (see Connecting a controller), run through these before packing up:

1. Register or confirm the Device Controller record — Vendor, Identity (4-120 characters) and Shared Secret Key (up to 64 characters). The Identity must equal what the controller sends in its redirect and as its RADIUS NAS-Identifier — one record per distinct value, see Identity and Virtual NAS — and the secret must match the controller's RADIUS setting exactly. A mismatch here doesn't error loudly; it just makes every login attempt fail RADIUS silently. A controller that was already sending RADIUS before its record existed can take up to an hour to be accepted.
2. Confirm CoA is reachable — Kiwire needs to reach the controller at the record's IP Address on its COA Port (3799 by default) to force disconnects or push session changes; this is a separate path from the controller-to-Kiwire RADIUS auth traffic, and it's easy to open one direction and forget the other.
3. Confirm the walled garden is in place — see Walled garden and redirect for exactly what needs to be allowed. This is the single most common reason a login page half-loads or never appears at all.
4. Check the vendor-specific requirements for whatever's actually installed — your vendor's setup guide lists which port needs to be reachable (RouterOS's API on 8728 for device bypass, the UniFi controller port 8443, and so on) and which RADIUS attribute — if any — enforces data caps, versus falling back to Session-Timeout.

Simulate a login

Before testing on the real guest network, Portals › Troubleshoot › Portal Simulation (view-portal-simulation permission) lets you run through a login inside Kiwire's own admin without touching the physical hardware — useful for catching a broken journey or template issue before you're standing next to the AP. It's not a substitute for the next steps, though: simulation loads the portal directly over HTTPS with no walled garden or redirect involved, and all URLs in the frame load normally regardless of what the controller's walled garden actually allows — so a simulation that works tells you the portal logic is fine, not that the network path to it is. SMS and WhatsApp OTP, if used, do send real messages during simulation, so use a phone number you can actually check. Test logins in simulation also create real session records in the tenant database — if you want to keep test data out of your reports, use a dedicated test account you reset afterward rather than a real guest's credentials.

Check the controller test page

Portals › Troubleshoot › Controller Test (view-controller-log permission) is the real-network counterpart to simulation: it opens a live capture window and shows exactly what the controller sends when a guest is redirected to Kiwire — every parameter, as a pass/fail checklist — without you needing to read web server logs. Run an actual test login from a device on the guest network with this page open. The capture lists redirects from controllers already registered in your tenant; if nothing shows up, either the redirect isn't reaching Kiwire at all (check the walled garden and the redirect URL on the controller first) or the identity it sends doesn't match a registered Identity — add the page's Test URL to the controller's redirect to see the hit anyway. If the request does show up but with missing or unexpected fields, that narrows the problem to the controller's own configuration rather than Kiwire. Controller Test covers the redirect only; it shows nothing about RADIUS, so a login that reaches the portal but never completes points at the shared secret or the NAS-Identifier.

Check accounting is arriving

A login without accounting will show the guest as connected but never produce a proper session record — worth confirming before you leave, not after a guest complains their usage looks wrong. Reporting › Login › Active Session (module Reporting - Login - Active Session) shows sessions Kiwire currently considers live, built from RADIUS accounting (Acct-Status-Type Start / Interim-Update / Stop) posted by the controller; your test login should appear there while the session is open, and disappear (or move to the historical login report) once it ends. A small number of cloud-managed vendors — UniFi console/cloud is the current example — never send RADIUS accounting at all, so Kiwire writes a synthetic session start itself and polls the vendor's own API for usage and the eventual stop; for those vendors, seeing the session appear confirms the poll is working, not that RADIUS accounting is flowing, since none is expected. Bear in mind the hourly login reports don't include the current, still-running hour — a session that just started won't show up in the aggregated reports yet even though Active Session already sees it.

Who to call

If the checks above don't turn up the cause, it usually comes down to which side owns the problem: nothing showing in Controller Test at all points at the controller's redirect or walled garden — that's the network/IT side, on the hardware in front of you. A request that reaches Controller Test but with missing fields, or a login that reaches Kiwire but fails, is a Kiwire-side configuration question — the Device Controller record, the zone/profile setup, or the licence. If accounting isn't arriving at all for a vendor that should be sending RADIUS accounting, that's also usually a controller-side setting (accounting server not configured, or pointed at the wrong port) rather than anything on the Kiwire side.