CRDA(8) Linux CRDA(8)NAME
crda - send to the kernel a wireless regulatory domain for a given ISO / IEC 3166 alpha2
SYNOPSIS
crda
Description
crda is the Linux wireless central regulatory domain agent. crda is intended to be used by udev scripts and should not be run manually
unless debugging udev scripts. crda is triggered to run by the kernel by sending a udev event upon a new regulatory domain change. Regula-
tory domain changes are triggered by the wireless kernel subsystem (upon initialization and on reception of country IEs), wireless drivers,
or userspace (see iw ). Upon a regulatory domain change the kernel sends a udev change event for the regulatory platform. The kernel
ignores regulatory domains sent to it if it does not expect them. The regulatory domain is read by crda from the regulatory.bin file.
RSA Digital Signature
If built with openssl or gcrypt support crda will have embedded into it an RSA digital signature which will prevent it from reading cor-
rupted or non-authored regulatory.bin files. Authorship is respected by the RSA public key packed into crda. This specific crda package
has been built with an RSA public key from John Linville (the Linux wireless kernel maintainer) and as such will only read regulatory.bin
files signed by him. For further information see the regulatory.bin man page.
UDEV RULE
A udev regulatory rule must be put in place in order to receive and parse udev events from the kernel in order to get udev to call crda
with the passed ISO / IEC 3166 alpha2 country code. An example udev rule which can be used (usually in /lib/udev/rules.d/85-regula-
tory.rules ):
KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda"
Environment variable
Set the COUNTRY environment variable with a specific ISO / IEC 3166 alpha2 country code and then run crda without arguments. This will send
a regulatory domain for that alpha2 to the kernel.
SEE ALSO iw(8)regulatory.bin(5)
http://wireless.kernel.org/en/developers/Regulatory/
crda 23 January 2009 CRDA(8)
Check Out this Related Man Page
IEEE80211_REGDOMAIN(9) BSD Kernel Developer's Manual IEEE80211_REGDOMAIN(9)NAME
ieee80211_regdomain -- 802.11 regulatory support
SYNOPSIS
#include <net80211/ieee80211_var.h>
#include <net80211/ieee80211_regdomain.h>
int
ieee80211_init_channels(struct ieee80211com *, const struct ieee80211_regdomain *, const uint8_t bands[]);
void
ieee80211_sort_channels(struct ieee80211_channel *, int nchans);
struct ieee80211_appie *
ieee80211_alloc_countryie(struct ieee80211com *);
DESCRIPTION
The net80211 software layer provides a support framework for drivers that includes comprehensive regulatory support. net80211 provides mech-
anisms that enforce regulatory policy by privileged user applications.
Drivers define a device's capabilities and can intercept and control regulatory changes requested through net80211. The initial regulatory
state, including the channel list, must be filled in by the driver before calling ieee80211_ifattach(). The channel list should reflect the
set of channels the device is calibrated for use on. This list may also be requested later through the ic_getradiocaps method in the
ieee80211com structure. The ieee80211_init_channels() function is provided as a rudimentary fallback for drivers that do not (or cannot)
fill in a proper channel list. Default regulatory state is supplied such as the regulatory SKU, ISO country code, location (e.g. indoor,
outdoor), and a set of frequency bands the device is capable of operating on. net80211 populates the channel table in ic_channels with a
default set of channels and capabilities. Note this mechanism should be used with care as any mismatch between the channel list created and
the device's capabilities can result in runtime errors (e.g. a request to operate on a channel the device does not support). The SKU and
country information are used for generating 802.11h protocol elements and related operation such as for 802.11d; mis-setup by a driver is not
fatal, only potentially confusing.
Devices that do not have a fixed/default regulatory state can set the regulatory SKU to SKU_DEBUG and country code to CTRY_DEFAULT and leave
proper setup to user applications. If default settings are known they can be installed and/or an event can be dispatched to user space using
ieee80211_notify_country() so that devd(8) will do the appropriate setup work at system boot (or device insertion).
The channel table is sorted to optimize lookups using the ieee80211_sort_channels() routine. This should be done whenever the channel table
contents are modified.
The ieee80211_alloc_countryie() function allocates an information element as specified by 802.11h. Because this is expensive to generate it
is cached in ic_countryie and generated only when regulatory state changes. Drivers that call ieee80211_alloc_countryie() directly should
not help with this caching; doing so may confuse the net80211 layer.
DRIVER REGULATORY CONTROL
Drivers can control regulatory change requests by overriding the ic_setregdomain method that checks change requests. While drivers can
reject any request that does not meet its requirements it is recommended that one be lenient in what is accepted and, whenever possible,
instead of rejecting a request, alter it to be correct. For example, if the transmit power cap for a channel is too high the driver can
either reject the request or (better) reduce the cap to be compliant. Requests that include unacceptable channels should cause the request
to be rejected as otherwise a mismatch may be created between application state and the state managed by net80211. The exact rules by which
to operate are still being codified.
SEE ALSO regdomain(5), ifconfig(8), ieee80211(9)BSD August 4, 2009 BSD