Contents
Central Regulatory Domain Agent
The Central Regulatory Domain Agent (CRDA) is a free software project to allow Linux (and possibly other operating systems) 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; more details below. When the 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.
Design
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.
Status
CRDA can be used in kernels kernels >= 2.6.28. It is required for 802.11d operation in 2.6.29.
Code
You can get the latest CRDA code from:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git
Usage design in Linux
In this section we cover how CRDA is used in Linux and how different types of drivers will cooperate with it.
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
License
CRDA is licensed under the ISC license in hopes other operating systems can benefit from a community project to enhance regulatory considerations.