The client that keeps dropping is a hardware address until a second file says whose it is.
Clients with names, ranked by what they did.
Charts no single file in the archive could produce. The floor from sheet A-01, read as a schedule.
Hardware addresses are matched against the fingerprint table in the same upload. A candidate that resolves nothing is not used, so what you see are real matches rather than a guess.
Clients ordered by how often they dropped rather than how often they connected. The device with a problem sorts to the top instead of the device that is simply busiest.
Connections grouped by what kind of device made them and what they were running, so a fault that only affects one fleet or one platform is visible as a shape rather than a hunch.
Point a question at the archive in plain language and get a cited answer.
Wi-Fi problems are spread across files that do not reference each other.
Each file is readable. The answer is in the relationship between them.
An association log is a list of hardware addresses joining and leaving. Which of them is the handset a nurse carries, and which is a printer nobody has touched in a year, is not in that file.
What band a client was on, what the retry and steering settings were, whether the network was even advertising at the time: all in configuration files sitting beside the log, in a different format.
A busy access point logs thousands of joins and leaves a day. Picking the one client whose pattern changed means counting, and counting by hand across a week of logs is nobody's job.
Put the access point's files in one archive.
The relationships are worked out from the contents. One archive, four kinds of sheet; only the first is required.
Association and authentication daemon output: clients joining, leaving, failing to authenticate, and the reason codes that came with it.
Access point configuration and router settings are recognised as configuration rather than prose, so what the radio was set to is read alongside what it did.
A table mapping hardware addresses to device names, types and operating systems. This is the file that turns the log into something you can read.
A capture taken on the same network is read as structured records: protocols, conversations, and the exchanges behind a failed association.
Three situations an access point archive turns up in.
And what the join gives you in each. The same floor from sheet A-01, three times.
Handsets losing the network in a way nobody can reproduce on demand. The clients are resolved to real devices, ranked by disconnects, so you can see whether it is one model, one floor, or one radio.
An association log read as a device population rather than a list of addresses, split by type and operating system, with anything the fingerprint table cannot identify reported as unidentified rather than quietly dropped.
Upload the archive from before and the one from after. The comparison, Delta, names what differs between them on one shared clock, rather than leaving you to diff two directories by eye.
What this is not.
This reads the files an access point and its network produce: logs, configuration, client tables and captures. It is not a radio survey, a spectrum analyzer or a live monitoring agent, and it does not measure signal quality it was never given. If the answer is not in the files you uploaded, it will say so rather than infer it.
Frequently Asked Questions
At minimum the access point's log. Add the client fingerprint table and the resolution from hardware address to device name becomes possible; add the radio configuration and what the access point was set to is read alongside what it did. Put them in one archive and upload that.
The logs are still read, counted and searchable, and the clients stay as hardware addresses. Nothing is invented to fill the gap, and the analysis says which clients it could not identify.
Yes. Router configuration in that style is recognised as configuration rather than read as prose, so it is used as context for the logs beside it.
It can tell you what the logs recorded: when the client left, what reason code came with it, and what the access point was configured to do. It cannot tell you what the radio environment was doing, because that is not in the files.
Your log data is encrypted in transit (TLS 1.3) and at rest (AES-256), processed in your own tenant, and never used to train AI models. See the architecture page for where data goes and what leaves your environment. Files are deleted after 90 days, or immediately from your dashboard. Enterprise plans offer on-premise deployment for regulated or air-gapped environments.
Bring us an access point archive.
Logs, config and the client table from one site. From there we will scope a pilot for your team.
A-02 radio and router config
A-03 client fingerprint table
A-04 packet captures