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

Regulatory information

We take regulatory considerations seriously as its one of the major key components to getting proper vendor support on drivers. Despite the fact that drivers and hardware can have their own regulatory solutions we provide this framework as a safety net for regulatory considerations to account for changes and updates on regulatory rules world wide and to provide an API to allow drivers to export their own regulatory restrictions. Our regulatory infrastructure consists of three major components:

The Central Regulatory Domain Agent (CRDA) is allows Linux (and possibly other operating systems) to comply with radio spectrum regulations around the world by enforcing the regulatory requirements in software. CRDA is also aimed to encourage Linux support from the vendors who were previously afraid to support Linux drivers that would not follow the requirements for radio spectrum use.

We maintain a thorough and flexible regulatory database in userspace and provide CRDA, a userspace agent, which can be triggered to update the kernel wireless core's definition of the regulatory permissions for a specific country. Keeping the database in userspace allows distributions to provide updates without kernel upgrades. The database is shipped in binary form using a binary file format designed for size efficiency that also includes an integrity check. When a regulatory domain change is detected (for example by observing an AP with country information), the kernel will request, from CRDA, the regulatory permissions for the new domain to enforce those at drivers.

For some hardware, regulatory permissions are programmed into the EEPROM, these can be observed as well, depending on the driver. Some drivers rely on EEPROM values for enforcement or calibration and drivers can continue to rely on these values by filtering the CRDA data according to the EEPROM settings. For these type of drivers, CRDA provides an extra layer of regulatory compliance, for instance when the card is in a laptop that roams between countries.

Kernel integration

We have factored common regulatory driver code as part of the wireless stack and provided a way for a userspace agent to update the currently set regulatory domain. An important component to Linux' own kernel integration is to allow drivers themselves to hint to the wireless core an alpha2 and have a callback to review the data passed by crda based on its own driver or EEPROM data. This allows vendors to use their own regulatory information to help enhance regulatory compliance even further. For more details on the Linux kernel integration see how you can set the regulatory domain.

CRDA

CRDA is our userspace agent which uploads regulatory domains into the kernel, it acts as a udev helper.

The regulatory database

CRDA requires a regulatory database (Web view or gitweb) to be build and maintained. Our hope is that this database can be used by other platforms (open or proprietary), not just Linux. John Linville maintains this database through the wireless-regdb git tree:

git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git

The regulatory.bin file there is signed with his RSA private key. We keep the RSA public key embedded as part of CRDA which allows us to verify the authorship and integrity of the regulatory database.

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. This ensures regulatory.bin file authorship and integrity.

Sending updates to the regulatory database

If you find any errors please send them to the linux-wireless mailing list, either as patches to the db.txt file from the wireless-regdb git tree, or just tell us what is wrong in plain English.

Patches sent to the wireless-regdb git tree should be addressed as follows:

To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org
Subject: wireless-regdb: Update regulatory rules for France (FR) on 5GHz

This is a static dump of the wiki, taken after locking it in January 2015. The new wiki is at https://wireless.wiki.kernel.org/.
versions of this page: last, v66, v65, v64, v63, v62, v61, v60, v59, v58, v57, v56, v55, v54, 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