01
Disconnections and reconnections
Sessions drop in a particular area, along a route, after switching access points, or without an obvious pattern.
Diagnosing the causes of problems in an existing network
Wi‑Fi network audit and optimization plan
We start with the observed symptom and check for possible causes in the radio layer, configuration, wired network, client device and application. The result of the audit is a well-founded diagnosis, a priority action plan and a way to check the effect of the changes.
Symptom → radio / configuration / LAN / client / application → diagnosis → action plan
What question does the Wi‑Fi network audit answer?
An audit of the Wi‑Fi network establishes the probable or confirmed cause of the existing infrastructure problems and forms a verifiable action plan. Depending on the symptom, radio measurements, WLAN configuration, wired path, client devices and application are analyzed. Wi‑Fi site survey can be one of the audit methods, but it does not replace the diagnosis of the entire chain. Corrections, migrations and re-checking are performed separately unless they are expressly included in the contract.
What symptoms require diagnosis
02
Low or unstable speed
Performance varies with the time, area, frequency band, client device model, load, or path to the application.
03
Different behavior of client devices
Some models work reliably while others connect slowly, remain associated with a weak access point, or lose connectivity.
04
Problems after the changes
Problems appeared after network expansion, updates, or changes to channels, policies, the LAN, or applications.
What data is needed for the audit
| Required | Useful to have | We will clarify this together |
|---|---|---|
| Description of the symptom: where, when, what and how it manifests itself | WLAN/LAN layout and list of equipment with versions | Secure way to transfer configurations and logs |
| Client device models and application names | Depersonalized logs, time stamps, history of changes | Whether a site visit and field measurements are needed |
| Technical owner's contact details | Plans, problem routes, current radio settings | A reproducible test scenario and criteria for confirming resolution |
Do not use the standard form to send passwords, keys, tokens, personal data, or complete configurations containing secrets. Agree on a secure channel for sensitive materials.
The layers we examine
01
Radio layer
Coverage, interference, channels, transmit power, observed utilization, and connection events, as far as the available data allows.
02
WLAN configuration
SSIDs, security, roaming mechanisms, policies, and compatibility of settings with client devices and requirements.
03
Client devices
Models, drivers, point selection behavior, energy saving, and platform differences.
04
Wired network and services
Ports, VLAN, DHCP, DNS, authentication, routing and dependencies, if access to them is included in the audit.
05
Applications and workflows
Traffic path, sensitivity to delay and loss, time and conditions of symptom reproduction.
How the audit is conducted
- 01
Document the symptom and the initial state
Agree on the scenario, time stamps, affected devices and the criterion by which the change can be checked.
- 02
Collect the available data
Collect diagrams, anonymized logs, configurations, and measurements through an agreed secure process.
- 03
Reproduce the problem and test hypotheses
We divide possible causes into layers and perform only agreed safe tests.
- 04
We establish the diagnosis and priorities
For each conclusion, identify the supporting data, confidence level, impact, and dependencies.
- 05
We provide an action plan and a verification method
Describe the order of changes, risks, rollback conditions and data to be compared after implementation.
What the customer receives
- 01Description of symptoms, boundaries and initial state;
- 02A list of hypotheses tested and the data used;
- 03Conclusions with confidence and limitations;
- 04A prioritized action plan addressing causes rather than general symptoms;
- 05Risks, dependencies and recommended order of changes;
- 06Retesting method and comparison criteria;
- 07A list of issues that cannot be closed without additional data.
What is included and what requires a separate agreement
| Included in the base scope | Agree separately | Not included automatically |
|---|---|---|
| Interview, analysis of provided data, hypothesis testing and diagnostic report | Site visits, Wi‑Fi site surveys, extended telemetry collection, and laboratory tests | Implementation of recommended changes |
| Priority action plan and verification method | Validation after changes | Equipment replacement, migration, or a new network design |
| Documenting limitations and confidence levels | Analysis of systems outside the agreed access area | A guarantee of resolving the symptom without implementing and validating changes |
How the audit quality is checked
| Criterion | How to check | Where we document |
|---|---|---|
| Link to the symptom | Each conclusion responds to a specific observation or test | Matrix of symptoms and hypotheses |
| Reliance on data | Identify the source, time, conditions, and limitations of the data | Diagnostic report |
| Separation of fact and hypothesis | The conclusion states its confidence level | Register of conclusions |
| Implementation of the recommendations | Order, dependencies, risk and verification are indicated | Plan of Action |
| Reproducibility of verification | The client, route, application and comparison metric are defined | Retest program |
What determines timeframes and cost
The estimate depends on the number of sites and network segments, platforms and versions, availability of diagrams, configurations and logs, reproducibility of the symptom, client device models, site visits, field tests, and the depth of analysis of related systems. An initial estimate requires a symptom description, timestamps, a network diagram, and an equipment list.
Questions and answers
Frequently Asked Questions About Wi‑Fi Network Audit
01How is an audit different from a Wi‑Fi site survey?
A Wi‑Fi site survey collects field data on the RF environment, coverage, and agreed routes. An audit starts with a specific symptom and investigates possible causes across the RF network, configuration, LAN, client device, and application. On-site measurements may form part of the audit when a hypothesis cannot otherwise be confirmed or ruled out, but they do not replace analysis of the other data.
02Will you fix the settings as part of the audit?
The base audit concludes with a diagnosis, a prioritized action plan, and a method for checking the expected effect. Configuration changes, equipment replacement, and deployment of a new design are agreed separately so that scope, risks, work windows, backups, and rollback are defined in advance. If diagnosis requires a test change, its scope and conditions are also agreed before any intervention in the live network.
03Is it possible to conduct an audit remotely?
Some analysis can use diagrams, anonymized logs, configurations, and a secure remote session if the available data is sufficient. A site visit is needed when the symptom relates to the actual RF environment, a route, or installation, or cannot be reproduced remotely. We determine the audit format after reviewing inputs, access permissions, security restrictions, and the required depth of findings.
04What materials should be provided?
Provide a symptom description, its location and timing, client device models, the application, a network diagram, and an equipment list with versions. Anonymized logs, a change history, plans, and affected routes are useful. Passwords, keys, tokens, personal data, and complete configurations containing secrets must be transferred through a separately agreed secure channel rather than the standard form.
05How do you prove the cause of the problem?
Each conclusion links the observed symptom to the data used, the hypothesis tested, test conditions, and known limitations. If the data is insufficient, the finding remains a hypothesis with a proposed method of verification. Events occurring at the same time do not by themselves establish causation: a confirmed diagnosis requires a reproducible observation, a test, or a consistent set of independent evidence.
06Is retesting after changes included?
Retesting is included only when explicitly specified in the agreed scope. The baseline report should define the client device, area or route, application, conditions, and comparison metric used to verify changes. Implementation and retesting may be separate stages, particularly when they require a site visit, a maintenance window, access to related systems, or other contractors.
The next step
Describe the symptoms of the current network
Specify where and when the problem occurs, which devices are affected, and which application is involved. Provide an anonymized diagram or logs without passwords or keys. We will identify any missing information needed to estimate the audit.
Material prepared by Connectum technical team · updated: August 2026
Do not use the standard form to send passwords, keys, tokens, personal data, or complete configurations containing secrets. Agree on a secure channel for sensitive materials.