Automatic Channel Selection for Embedded Access Points: Check the Survey Data Before Choosing

An automatically selected channel is only as defensible as the candidate set and survey evidence behind it. First establish which ACS implementation ran, then audit field availability, observation coverage and scoring policy. A channel number printed at startup is not proof that every eligible alternative was measured or that the selected channel will remain suitable under later load.

This guide pins hostapd 2.11’s software survey-based ACS and Linux 6.12 survey contracts. Use CONFIG_ACS and the actual shipped configuration as the reference. Driver-offloaded ACS, multi-link policies and EHT puncturing require separate qualification. Keep the real jurisdiction, approved hardware configuration and required DFS behavior intact; candidate eligibility is a prerequisite, not something the scoring algorithm may override.

Identify the algorithm before interpreting its logs

The hostapd 2.11 configuration supports survey ACS through its automatic channel setting. In acs_init(), however, the ACS-offload capability selects the driver path. When offload runs, do not claim that hostapd’s software survey formula chose the result. Ask for the supported driver/firmware decision evidence instead. hostapd 2.11 hostapd.conf and src/ap/acs.c

For software ACS, record band, intended width, permitted candidate restrictions, scan count and channel-bias configuration. Selection depends on these inputs, not just a list of observed neighboring SSIDs. The official Linux Wireless overview describes survey-based ranking, but its introductory equation is not a substitute for the exact tagged implementation. Linux Wireless ACS overview

Separate field presence from trustworthy measurements

In 2.11, acs_survey_is_sufficient() requires noise floor, channel time and at least one of busy time or receive time. It checks field-presence flags. It does not establish that the sample has a useful positive duration, a representative observation window or internally consistent arithmetic.

The driver contract also matters: Linux survey fields are optional, and a survey can represent global statistics rather than a particular channel. Confirm that the driver-to-hostapd integration supplies the intended per-channel data. Do not transform a missing field into zero so the sample appears complete. Linux 6.12 survey_info and validity flags

Use a per-candidate ledger with frequency, eligibility reason, sample count, observation intervals, valid fields, duration, busy/RX source, optional own-TX time and rejection reason. A channel with no usable observations belongs in “unmeasured,” not “quiet.” The software’s preliminary sufficiency check can succeed when some usable survey data exists; it is not a guarantee of complete coverage across every candidate.

Read the actual score and its assumptions

The pinned factor function uses busy time when present and falls back to receive time otherwise. If own-TX time is present, it subtracts that value from both the selected busy/RX numerator and the channel-time denominator. It adds a noise-floor term and applies its implemented noise-dependent multiplier. Thus a generic busy/active percentage is not the complete hostapd score.

This arithmetic assumes meaningful supplied counters. For example, if own-TX time exceeds the selected busy/RX value, the numerator can become negative. The presence check alone does not reject that input. Qualify the driver’s accounting or flag the observation as unsuitable for a defensible decision; do not silently clip or rewrite measurements while claiming to reproduce the original algorithm.

The implementation averages sufficient samples for a channel. Candidate evaluation then considers width and, on 2.4 GHz, weighted neighboring-channel contributions. Configured channel bias multiplies the resulting factor; a default preference also exists for common 2.4 GHz channels when no bias list is supplied. Consequently, the lowest raw busy fraction need not produce the selected channel. These are implementation choices, not universal RF quality laws. hostapd 2.11 ACS sufficiency, factor and candidate-selection functions

A wide-channel result needs evidence about its constituent spectrum, not just its primary channel. For a first qualification campaign, a supported 20 MHz configuration can simplify the interpretation. Broader bandwidth remains a distinct case with its own coverage ledger and operating constraints.

Make incomplete coverage an explicit decision

Do not require the product to report “best available channel” when only a subset has usable measurements. It may be acceptable to choose among a documented supported subset, but the report must say which subset was compared and why others were excluded. An eligible channel with missing surveys is different from a channel excluded by configuration or operating restrictions.

If software survey study has no sufficient data, the pinned implementation fails that study. Its source contains a future-work comment about BSS-based fallback, not an implemented guarantee that counting APs will rescue the selection. Do not promise that fallback in a product specification. Handle ACS failure through the product’s approved startup policy and retain the actual error. hostapd 2.11 acs_study_survey_based() and acs_study_options()

Run a repeatable startup campaign

1. Capture the effective candidate set. Record allowed frequencies and widths after hardware, deployment and configuration restrictions. Do not treat a scan result as permission to operate an AP there.
2. Collect the actual ACS inputs. Preserve sample validity, durations and source fields for each candidate. Record driver/firmware versions and whether selection was offloaded.
3. Check quality before comparing scores. Flag missing candidates, zero observation time, inconsistent counters and stale or mixed observation windows. Distinguish a product qualification gate from checks that hostapd itself performs.
4. Explain the selection. Retain usable-sample counts, calculated factors, applicable neighboring-channel contributions and bias. A changed bias is a changed policy, even with identical RF observations.
5. Repeat under authorized representative load. Compare controlled quiet and normal competing-traffic cases on your test network. Repeat cold starts at different workload phases; do not create disruptive interference or select only favorable runs.
6. Verify the resulting service. Confirm AP startup, actual operating channel/width and representative client service. Record failed startup and incomplete evidence as outcomes, not discarded trials.

More scans collect more observations but also affect startup time; they cannot repair an unsupported survey field. Startup ACS does not by itself provide a continuous reassessment and safe channel-switch service. If the product needs runtime adaptation, specify its trigger, client impact and separate supported mechanism.

Use bounded execution evidence honestly

A host fixture compiled the exact two 2.11 sufficiency/factor functions with minimal declarations and logging stubs using GCC 14.2. Eight groups checked busy selection, RX fallback, own-TX subtraction, missing fields and noise contribution. It also demonstrated that the presence gate accepts zero-time and inconsistent TX/busy examples. These were synthetic inputs, not observed driver defects.

AddressSanitizer and UndefinedBehaviorSanitizer ran with leak detection disabled because this execution environment cannot run LeakSanitizer under its tracing arrangement. No full hostapd process, scan, ranking campaign or radio was exercised.

For a hypothetical AP, candidate A has complete observations while candidate B lacks noise data. Selecting A does not establish that B was busier. Release with the measured comparison set and its limitations, then verify service on the chosen configuration. That is stronger evidence than an unexplained “auto” setting.