Hidden SSIDs in IoT Onboarding: Scan Results, Directed Probes and User Input
A missing list entry is an observation, not a verdict
An onboarding screen that lists nearby networks is a discovery interface, not an inventory of every network the device could join. If the required name is absent, offer a manual-network path before asking the customer to reset the router. First distinguish three outcomes: no scan completed, a scan completed without a named match, and association to a supplied profile failed. They need different messages and different evidence. This guide addresses a station joining a non-broadcast SSID, with Linux nl80211 and the AOSP android16-release supplicant configuration as a concrete reference. It does not claim that every radio firmware exposes the same controls. TI’s provisioning primer supplies the broader distinction between collecting network information and connecting the station.
Record what the scanner actually returned
Keep each scan generation separate. Record completion status, duration, channels examined when available, and whether the result is fresh or cached. A blank-name BSS entry can still contain a BSSID and radio information; do not rename it to the user’s supplied SSID merely because the signal is strong. Conversely, some SDKs suppress blank-name entries entirely. Establish that behavior with the SDK documentation and controlled captures. A phone successfully joining the network only proves that phone’s discovery and stored-profile path worked. It does not establish the embedded device’s regulatory channel permissions, scanning behavior, or saved-name knowledge. Product support should ask for the AP’s actual channel and configured name through a private diagnostic workflow, rather than treating a phone screenshot as proof that the embedded scan is defective.
Use directed discovery only for a supplied profile
The verified AOSP configuration reference describes scan_ssid=1 as requesting SSID-specific probe scans and notes extra scan latency. With nl80211 it documents ap_scan=1; changing to ap_scan=2 is not a general hidden-network fix. Treat these as implementation-specific settings, not portable SDK names. A bounded directed attempt should use the exact supplied SSID and the selected security profile. It should not cycle through a large historical list indefinitely. A scan request accepted by an API is also not proof that every desired channel was probed: the driver and regulatory state still constrain execution. Capture request time, completion time, and association transition separately, so a scan timeout cannot masquerade as an authentication failure.
Make manual entry preserve the user’s intent
Provide explicit fields for network name, security mode, and the corresponding credentials, plus a clear hidden-network option where the platform needs it. Preserve case and whitespace; do not silently trim or normalize a supplied name. Show a byte-length error when the encoding exceeds the interface limit. Keep the submitted candidate separate from the last working profile until connectivity reaches the product’s defined success condition. If the user cancels, cancel pending attempts and remove any temporary profile according to the chosen retention policy. A failed manual attempt should leave the editable name visible while keeping the credential concealed. Explain that an exact name is required, without suggesting that hiding a network improves its authentication strength.
Account for channel and privacy boundaries
A hidden profile cannot grant permission to transmit on a prohibited channel. Linux 6.12 cfg80211 channel flags distinguish disabled channels from NO_IR, which includes restrictions on initiating probe requests. Check the actual device and deployment region before interpreting a directed-scan failure. Also explain the privacy trade-off: NetworkManager’s hidden-network setting warns that explicit probes can reveal recognizable network searches. Restrict stored hidden profiles and background probing to what the product actually needs. Do not put SSIDs or BSSIDs in public support URLs. In ordinary logs, a short-lived local profile identifier, name length, attempt number and failure stage are usually more useful than a persistent raw-name history.
Run a controlled discovery matrix
Use an authorized test AP and keep its security mode and radio channel fixed while changing only SSID broadcast behavior. For each run, clear the device’s scan cache through the supported interface or record its age; do not erase user credentials just to make a test convenient. Compare ordinary scanning, a manually supplied exact name, a deliberately wrong name, and an AP that is powered off. Then repeat with a supported legal channel that has a different scan policy. Include two APs sharing one SSID and an unrelated blank-name BSS, because a UI that merges by display text can select the wrong record. This is a proposed test plan, not a claim that these combinations have been tested on a particular board.
Accept a diagnosable result, not merely one successful join
The release gate should require a usable manual path after an empty list, byte-exact name handling, bounded attempt duration, and recovery to an editable screen. Verify that “network not discovered,” “association rejected,” and “address assignment failed” remain distinct. A successful run should retain the selected profile without pinning an incidental BSSID unless that was an intentional deployment requirement. A failed run should preserve enough non-secret evidence to repeat the scenario. Define a support escalation bundle containing firmware version, driver version, regulatory state, scan status, AP channel and staged timestamps. Hidden-network support remains conditional on the target stack and lawful channel behavior; the acceptance checklist should state those boundaries instead of promising that manual entry can always overcome invisibility.
