Off-Channel Wi-Fi Scans: Budget the Service Gap on an Active Control Link

A scan request can complete successfully while an active control link suffers unacceptable interruption. Measure the longest useful-service gap and the actual off-channel intervals separately. Total scan duration is not automatically the outage duration: a radio may revisit its home channel, queue traffic, offload scanning or share work across hardware resources.

This guide uses Linux 6.12 cfg80211 and mac80211 contracts. It focuses on an already associated infrastructure client and its exact driver/firmware scan implementation. Multi-radio and multi-link operation need explicit additional evidence. Hidden-network discovery, roaming thresholds and channel-availability diagnosis are outside scope. All scan channels and active transmissions must remain permitted for the actual deployment jurisdiction and product configuration.

Use four different time intervals

Interval	Endpoints	Meaning
Request latency	Application request to accepted/rejected response	Control-path handling, not completed scanning
Scan lifetime	Accepted request to terminal completion	Ownership and scan operation duration
Off-channel residence	Departure from home channel to return	One interruption opportunity on the observed radio
Useful-service gap	Last valid operation to next valid operation	Application-visible interruption, including other delays

Record repeated off-channel intervals rather than compressing them into one bar. Home-channel returns may permit progress, but their existence does not prove that queued control traffic actually ran. Conversely, a long scan lifetime can contain several short interruptions. The product’s acceptance limit applies to useful service, while the channel timeline helps explain it.

Read the request and completion contract

For Linux 6.12’s cfg80211 driver API, returning zero from the scan callback transfers the request to the driver until it reports completion through cfg80211_scan_done(). The abort callback tells the driver to stop an ongoing scan, but the driver must still indicate the result through that completion path. Scan results can be reported outside a particular request/completion bracket, so the mere appearance of a BSS result is not a terminal event. Linux 6.12 cfg80211_ops scan contract

At the mac80211 boundary, hardware-scan cancellation similarly completes only when the driver calls ieee80211_scan_completed(). The hardware-scan callback can also return the documented special value requesting a software scan. Record which path actually ran; do not assume that a device advertised as scan-offload capable used offload for every attempt. Linux 6.12 hw_scan and cancel_hw_scan contracts

For application integration, serialize scan ownership with the existing network manager or supplicant. Avoid a second periodic scanner that overlaps the owner’s work and obscures which request produced an event. Give each application request an epoch and preserve busy/rejected, accepted, completed and aborted outcomes separately.

Treat dwell settings as implementation inputs

The 6.12 scan-request structure expresses per-channel duration in time units. Without duration_mandatory, the duration is a maximum and actual dwell may be shorter; with it, the requested duration is mandatory. The nl80211 extended feature SET_SCAN_DWELL identifies driver support for dwell configuration. Confirm the exposed userspace path and driver behavior before assuming a requested value was applied. cfg80211_scan_request; Linux 6.12 scan-dwell capability

Multiplying channel count by requested dwell is only a planning model. Channel-switch time, home-channel returns, scheduling, passive requirements and other radio work affect the observed operation. Neither a shortened list nor a small requested dwell guarantees a control deadline. Do not remove required regulatory behavior, force active probes on prohibited channels or change country settings to make the test faster.

Run a scan-specific service campaign

1. Establish a no-scan baseline. Keep the client associated to a fixed approved AP configuration. Run sequence-tagged control transactions at representative cadence and record normal latency, missing outcomes and endpoint load.
2. Identify automatic scan sources. Record manager, supplicant and firmware policies. If a supported laboratory control suppresses an automatic source, document that change and restore it later. Otherwise retain its events as possible overlapping work.
3. Trigger one bounded scan. Use the owner’s supported API and record request, acceptance, actual scan start where exposed, channel visits, completion and application operations. Capture only an authorized test network and avoid unnecessary network identifiers in reports.
4. Vary phase, not just frequency. Start scans at different offsets relative to the control transaction. A scan synchronized between commands can hide the worst observed overlap. Keep failed and timed-out operations in the denominator.
5. Compare supported scan workloads. Contrast the product’s full required scan with a justified narrower legal channel set or supported dwell change. Record discovery coverage as well as service impact; a short scan that misses needed networks is not a complete success.
6. Exercise cancellation. Request cancellation during an accepted scan, observe terminal completion, then verify useful service resumes and a later scan can be accepted. Do not launch replacements merely because the abort request returned.

Repeat under normal and representative loaded conditions. Keep aggregation, power policy and roaming behavior documented so a scan-correlated pause is not assigned to the wrong mechanism. If actual channel residence is unavailable, label scan lifetime as the available proxy and do not rename it “off-channel time.”

A hypothetical timing interpretation

Suppose an illustrative scan lives for 70 ms and contains two 20 ms off-channel visits separated by a home-channel interval. The summed off-channel residence is 40 ms and the longest individual visit is 20 ms. Neither number proves the application gap. If the last useful response is at 8 ms and the next at 65 ms, the observed service gap is 57 ms and needs an explanation including queueing and scheduling.

Those values are synthetic, not measured radio timings. Their purpose is to prevent a report from claiming that total dwell equals maximum interruption, or that a home-channel return guarantees immediate application service.

Choose the release boundary

No scan, cancellation request or radio timing experiment was executed for this article. The pinned source contracts were inspected; the campaign is proposed target qualification.

Approve a scan policy with an application-gap requirement, discovery-coverage requirement, cancellation behavior and exact hardware/software scope. If the radio cannot meet both service and discovery needs concurrently, schedule scanning within an approved maintenance window or redesign the resource allocation. Do not promise a zero-gap background scan merely because the request is asynchronous.