What Vloka does

Floor plans

Upload your building drawings and place the access points where they physically are. From then on the plan is the screen you work from: which AP a client is on, where it walked, which radio it used, and what the signal was along the way.

Your own plans — DWG, PDF or an image. North is something you set, and the compass reads it back in words so a plan that was drawn sideways stops being a trap.
Distance rings from a path-loss model. The default exponent is there for orientation; anything presented as a measurement comes from measurements.
A client's walk drawn on the plan, with the roam events on it — including the ones where it stayed on a far AP it should have left.

Coverage maps need measurements, and Vloka insists on it

A heat map is only drawn for a floor and a band that has a calibration fit behind it. Walk the floor once, tapping where you are, and Vloka fits the model to what it measured. Without that it draws nothing and says why — a predicted map looks identical to a measured one, and a decision made on the wrong one costs a site survey.

Troubleshooting that starts with the complaint

The Cisco controller has everything, and that is the problem: you have to know what to look for, read it, understand it, and then do something. Vloka takes that over.

Client check — one MAC in, and the whole story out: which AP, which band, the real authentication method (from method-id, not the WPA version), the device type, the signal, and what it has been doing.
Live diagnostics Vloka runs itself — capture points, debug wireless mac, platform conditions. It turns them on, reads them, turns them off and checks that they really are off.
Roaming analysis — where a client moved, when, and whether it should have.
Config check — reads the controller's configuration and reports what does not hold together, in the words of the thing it is talking about.

Vloka is read and write with permission. An account that can only read cannot start a debug or a capture point, so it needs more than read — and it says exactly what for. What it never changes without asking first is anything that carries traffic or outlives the session: WLANs, policies, interfaces, tags. Those go through an explicit opt-in, are audited, and verify their own teardown.

Logs that explain themselves

Controller and appliance logs, with the mnemonic explained from a grounded library and the appliance's own diagnostics. Not from a language model that will produce a fluent explanation for a message it has never seen — a wrong explanation of a log line is worse than none, because it gets believed and acted on.

A mnemonic Vloka does not know is recorded locally as unknown. That list is the roadmap for what gets written next. Nothing about it leaves your appliance.

Access points, clients and controllers

Inventory of every AP with its history — where it was, what changed, when it was last seen, and whether somebody is working on it (which is not the same as down, and is not coloured as though it were).
Band is read from the explicit radio type, never guessed from a channel number — 6 GHz and 2.4 GHz share numbers and guessing gets it wrong.
Everything a page reads from the controller goes through a cache. One open floor-map tab once cost 7,200 RESTCONF requests an hour; it does not any more.
Up to four controllers per appliance, and an HA (SSO) pair counts as one — it has a single management address and answers as one box. A failover keeps the access points Vloka already knows instead of reporting the switchover as an outage. A site whose controller sits behind a link too poor to run it centrally gets its own Vloka rather than a longer tunnel; see Editions.

Reports and exports

Excel, CSV and PDF from a branded template, of what is on the screen with the filters you applied — not of the whole table underneath it.

Guide me

Every page has a curated walkthrough that points at the thing it is describing. It is the manual, and a feature is not considered finished here until it has one.