> For the complete documentation index, see [llms.txt](https://docs.hamina.com/hamina/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hamina.com/hamina/onsite/site-surveys/network-configuration.md).
# Network Configuration
There are primarily three types of site survey:
* **Pre-Deployment Assessment Survey** - Surveys the current state of the network, or troubleshoots an existing one. This type of survey can also be used to perform Environment Learning, which can be used in the Simulation view for design work.
* **AP-on-a-Stick Survey** - Surveys one-to-several access points that have been temporarily deployed to measure signal propagation in the building. Can be used as an entire design methodology, or as a hybrid in conjunction with simulation work.
* **Post-Deployment Validation Survey** - Surveys a newly-deployed network to ensure that it sufficiently matches the simulation, and meets the defined network requirements.
Whether you make configuration changes to the network before surveying depends on what you want to show in the survey results. For example, if you want to show your manager or customer what the network looks like right now, you would not want to make any configuration changes.
If you want to improve the network as fast as possible, you might make a few obvious changes such as decreasing the channel width, increasing the transmit power, or increasing the minimum data rate. Then, you can survey the network and see what other changes or improvements you can make.
If you are performing an AP-on-a-stick survey, it's important to configure the AP as you intend to deploy it, while remaining open to adjusting the configuration based on what the survey results show while you are on-site.
For a post-deployment validation survey, deploy and configure the network as designed. Your survey results will then show you where the simulation differs from real-world measurements, and whether anything is misconfigured.
## AP Names
Most access points will include an **AP Name** in the Beacon, which Hamina Onsite can use to automatically name access points in the survey. This is very useful for mapping, planning, and troubleshooting purposes. Theoretically, it might consume a tiny extra amount of airtime, but we don't think it's enough to worry about.
Some vendors enable it by default, and some don't, citing security and privacy reasons.
To take advantage of this in Hamina, you need to enable this on at least one SSID that you are broadcasting, although enabling it for all virtual SSIDs that you broadcast will help Hamina group virtual SSIDs and AP radios together on the map.
When AP names are enabled, you should see the names reflected in the survey results:
### Missing AP Names
We support AP names on all major vendors such as HPE Aruba, Cisco, Fortinet, HPE Juniper, Meraki, Ubiquiti, and others.
If you've enabled AP names in your infrastructure and surveyed your network, and you still aren't seeing names, it's possible that we need to add support for your vendor. [Contact us at support@hamina.com](https://www.hamina.com/contact), where we will probably ask you to share your project with us via a link + password.
### Adding AP Names to an Existing Survey
If you already surveyed your network, but forgot to enable AP names, you don't nescessarily have to re-do the entire survey. To add an add names to APs, you can perform a partial survey, with the only requirement being that you "hear" each AP during the second survey. Taking a single [point survey](/hamina/onsite/site-surveys.md#point-survey) underneath or near each access point is enough to add the AP names.
## Hidden Networks
The one exception to the above applies to **Hidden SSIDs**. Hiding an SSID simply causes the network name to be removed from the Beacon, which is how access points advertise themselves to clients.
Since passive site surveys (which Hamina Onsite uses to create heatmaps) listen to Beacons from access points, a hidden network will produce a very sparse heatmap. You will see some measurements, but these come from Probe Responses.
While access points use Beacons to advertise themselves, a client can use a Probe Request to look for access points. When the access points return a Probe Response, it looks nearly identical to a Beacon, and includes the SSID so it can be identified by the client.
Hamina will treat Probe Responses just like Beacons and include them in measurements. But, since a client has to transmit a Probe Request to hear a Probe Response, Hamina Onsite will gather very few of them. The result will be a heatmap that shows only a few measurements.
{% hint style="warning" %}
**Recommendation**
Temporarily unhide your SSID during the site survey. Alternatively, if you are broadcasting both a hidden and an unhidden SSID, you can use the unhidden SSID for the majority of the analysis.
{% endhint %}
In general, Hamina does not recommend hidden SSIDs. They do not increase the security of your network, and arguably make it *less* secure. When an SSID is hidden, any clients who have connected to it must continuously send Probe Requests to look for the hidden SSID, which can be easily seen in a packet capture.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.hamina.com/hamina/onsite/site-surveys/network-configuration.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
