- Central Regulatory Domain Agent
- Host requirements
- Build requirements
- Letting the kernel call CRDA
- Dynamic reading of trusted public keys
- Changing regulatory domains
- Debugging kernel to CRDA communication
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. CRDA is intended to be run only through udev communication from the kernel. The user should never have to run it manually except if debugging udev issues.
CRDA is licensed under the ISC license in hopes other operating systems can benefit from a community project to enhance regulatory considerations.
You can get the latest CRDA code from:
You can get CRDA releases here
- regulatory.bin file
libnl >= libnl1
- python and the m2crypto package (python-m2crypto)
- libgcrypt or libssl (openssl) header files
- nl library and header files (libnl1 and libnl-dev) available at git://git.kernel.org/pub/scm/libs/netlink/libnl.git
- RSA public key of John Linville, we include this as part of this package so you do not need to install it. This RSA public key comes from the wireless-regdb.git tree and we keep it up to date here.
- regulatory database (regulatory.bin, no need to build just put the file in REG_BIN location) from:
Letting the kernel call CRDA
We use userspace events (uevents) to let the 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"
Dynamic reading of trusted public keys
CRDA can be built with gcrypt or openssl support. If using openssl (USE_OPENSSL=1) you can enable dynamic loading of trusted public keys and stuff. Trusted public keys can be put into the directory:
gcrypt support does not support reading public keys dynamically as gcrypt lacks a PEM parser.
Changing regulatory domains
Helping compliance by allowing to change regulatory domains
Linux allows changing regulatory domains in compliance with regulatory restrictions world wide, including the US FCC. In order to achieve this devices always respect their programmed regulatory domain and a country code selection will only enhance regulatory restrictions. This is in accordance with the FCC part 15 country code selection knowledge base publication number 594280. As an example if your device was programmed for operation in the US which allows operation on channels 1-11 on the 2.4 GHz band and you visit Japan which allows operation on channels 1-14 and you change your regulatory domain to JP you will not be able to use channel 12, 13 or 14 (CCK). But if you have a device programmed for operation in Japan and visit the US and you select US as your regulatory domain you will have channel 12-14 disabled.
Userspace applications can request the kernel to change regulatory domains. The following userspace applications currently allow you to do this:
Using iw to change regulatory domains
You can use iw from the command line as follows:
iw reg set US
Using wpa_supplicant to change regulatory domains
Get the wpa_supplicant (as of 0.6.7) and then add as part of your configuration file a line that has something like this:
Using Network Manager to change regulatory domains
This needs to be implemented, but since Network Manager uses wpa_supplicant it should just be a matter of adding a user interface option to let a user select an alpha2 and then adding the country entry into the wpa_supplicant configuration entered.
Debugging kernel to CRDA communication
To debug communication between the kernel and udev you can monitor udev events:
udevadm monitor --environment kernel