NOTE: this page is for archival only, see the note at the end of the page.

Central Regulatory Domain Agent

CRDA acts as the udev helper for communication between the kernel and userspace for regulatory compliance. It relies on nl80211 for communication.


The diagram below illustrates the current design of CRDA and its kernel interaction.

ASCII file format

Below is an example of a country entry for the db.txt regulatory file for EC (Ecuador)

country EC:
        (2402 - 2482 @ 40), (N/A, 20)
        (5170 - 5250 @ 20), (6, 17)
        (5250 - 5330 @ 20), (6, 23), DFS
        (5735 - 5835 @ 20), (6, 30)

Note that the frequency range (e.g. 2402-2482) covers the complete used bandwidth, so this definition allows using the 2 GHz channels 1 through 13 as 40 MHz channels. 5 GHz channels of a bandwidth of 20 MHz can be used if the frequencies used by the channel fit into the specified frequency ranges.

Binary file format

We define a new custom binary file format for use with CRDA, to have the data available quickly and as compact as possible as well as allowing to distribute the data along with the digital signature (see below) as easily as possible. The file format is defined in the regdb.h header file.

RSA Digital Signature

Integrity of the binary regulatory file is ensured by digitally signing the regulatory data using a private key and embedding the signature into the binary file. When the file is loaded by the regulatory daemon the signature is checked against a list of public keys built into the regulatory daemon binary.


CRDA can be used in kernels kernels >= 2.6.28. It is required for 802.11d operation in 2.6.29.


You can get the latest CRDA code from:


Usage design in Linux

For details please see mac80211 802.11d support and cfg80211 regulatory support sections.

Letting the kernel call CRDA

We use userspace events (uevents) to let he kernel speak to userspace. Below is an example udev rule you can place into your distribution's udev rules directory (usually /etc/udev/rules.d/). Note that most distributions have udev configured with inotify on the udev rules directory, so there is no need to restart udev after adding the new rule.

# Example file, should be put in /etc/udev/rules.d/regulatory.rules
KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda"

Debugging kernel to CRDA communication

To debug communication between the kernel and udev you can monitor udev events:

udevadm monitor --environment kernel


CRDA is licensed under the ISC license in hopes other operating systems can benefit from a community project to enhance regulatory considerations.

This is a static dump of the wiki, taken after locking it in January 2015. The new wiki is at
versions of this page: last, v53, v52, v51, v50, v49, v48, v47, v46, v45, v44, v43, v42, v41, v40, v39, v38, v37, v36, v35, v34, v33, v32, v31, v30, v29, v28, v27, v26, v25, v24, v23, v22, v21, v20, v19, v18, v17, v16, v15, v14, v13, v12, v11, v10, v9, v8, v7, v6, v5, v4, v3, v2, v1