An Embedded Wi-Fi Interface Is rfkill-Blocked: Find the Owner of the Block
When Linux reports an rfkill block, begin by identifying the affected rfkill object and its separate hard and soft states. Then find the hardware/platform or software policy that owns the state. Repeatedly requesting scans or changing credentials cannot establish that ownership, and repeatedly unblocking the radio can fight an intentional safety or operating policy.
This procedure is read-only until an authorized owner approves a recovery action. It uses Linux 6.12’s rfkill API and stable sysfs ABI, with systemd 256.6 as one explicitly optional state-restoration example. It does not assume a particular board switch, GPIO polarity, network manager or legal deployment region. An unblocked radio is only potentially available; it is not permission to transmit on every channel.
Read both state bits
Linux defines a hard block as a read-only radio block that software cannot override through the rfkill interface. A soft block is set by system software. Either blocks transmission. The hard-block label does not, by itself, identify a physical toggle on the enclosure: platform and radio drivers report the relevant state to the core. Their board-specific source must be established separately. Linux 6.12 rfkill documentation
| Hard | Soft | Interpretation | Next evidence |
|---|---|---|---|
| 0 | 0 | No block reported by this object | Continue ordinary device/link diagnosis if it still fails |
| 0 | 1 | Software block present | Identify policy, state-restoration or user-action owner |
| 1 | 0 | Hard block present | Trace the reporting driver and documented platform input |
| 1 | 1 | Both blocks present | Track both owners; removing one does not clear the other |
Prefer the separate hard and soft sysfs attributes over the older combined state attribute. The 6.12 stable ABI explicitly notes that the combined representation cannot express simultaneous hard and soft blocks. Its name is driver-assigned and type identifies the radio category. Do not assume that rfkill object zero is always the Wi-Fi device. Linux 6.12 sysfs rfkill ABI
Build a narrow object-to-device map
Record the kernel/BSP version, board revision, radio firmware and the actual interface/PHY identity. Enumerate the current rfkill objects, including each object’s name, type, hard/soft values and available device ancestry. Match the WLAN object to the intended hardware through the driver and sysfs device relationship. Preserve additional platform-level rfkill objects rather than assuming they are redundant duplicates.
If the expected object is absent, say so. Absence is not equivalent to “unblocked”; the device may not have registered an rfkill interface, or the relevant platform implementation may differ. Continue with bus/probe and driver evidence only after distinguishing that case. Do not manufacture an rfkill result from a generic “network unavailable” application message.
Use events for timing, not automatic attribution
The recommended /dev/rfkill interface supplies current device state after opening and subsequent addition, removal and change events. In Linux 6.12, the original event structure carries an index, radio type, operation and the two block bits. It does not carry the process ID of the software that caused a change. Extended events can add supported hard-block reason information, but do not turn the stream into a complete policy-owner audit log. Linux 6.12 rfkill UAPI
Use a supported read-only event monitor alongside timestamped platform and service logs. Treat device removal and re-addition as a new object lifetime; an index can identify a different lifetime later. If evidence collection begins after the block happened, label the current state as a snapshot rather than claiming to have observed its cause.
A change immediately after a network-manager action is a useful correlation, not proof of exclusive ownership. Check the service’s actual policy and log entry. Multiple components can request software state, and a platform event can coincide with a service restart.
Investigate the owner-specific branch
- Hard-block branch. Identify the driver reporting the state and the platform input it represents. Compare the schematic, board documentation and supported firmware diagnostics. A wrong polarity or stale resume report is a hypothesis requiring evidence, not permission to patch around the block.
- Soft-block branch. Inspect the network manager, product control service, operator radio setting and boot-restoration mechanism. Record the configured policy and which component is intended to be authoritative. Keep the investigation read-only until that owner approves a change.
- Boot-only branch. Compare early boot state with later service startup. Where systemd-rfkill 256.6 is actually deployed, its documented role is to restore state at early boot and save changes. A remembered block can therefore reappear without a new interactive action. This is an implementation-specific possibility, not an assumption about every Linux image. systemd 256.6 rfkill service documentation
- Resume-only branch. Correlate suspend/resume with the hard-state report and software policy. Linux’s driver guidance explicitly calls out platforms whose hardware state can change during suspend. Check the reported transition rather than equating a resume failure with missing firmware.
- Both-bits branch. Keep two causes open. Once an approved hard-block recovery occurs, read both values again; the soft block may legitimately remain. Do not declare recovery from a changed indicator alone.
A hypothetical handover to the right owner
Suppose a gateway boots with hard zero and soft one, while its platform input remains unchanged. A timestamped service log shows restoration of a saved blocked state before the network manager begins activation. That hypothetical evidence directs the issue to product radio-policy ownership and approved persistence behavior. It does not justify disabling the restoration service or forcing transmission.
Conversely, hard one after resume with no software-state change points toward the reporting driver/platform boundary. The support request should include the before/after state and board-specific input evidence. It should not ask the application team to retry passwords.
Acceptance and limitations
No target radio was unblocked, no system service was changed, and no rfkill hardware event was generated for this article. The state and event contracts were checked against the pinned official sources. Any target monitoring or recovery remains a proposed diagnostic procedure.
Close the case only when the affected object, block kind, authoritative owner and approved recovery are explicit. After recovery, separately verify association and the application service. Keep regional channel restrictions, DFS requirements and product operating permissions intact; clearing an rfkill condition does not override any of them.
