Understanding the Linux WiFi regulatory system

Jump to: navigation, search

Understanding the Linux WiFi regulatory system is not a straightforward endeavor due to the competing needs in its design. It needs to make it difficult enough for users to modify in unintended ways but simple enough for educated developers to understand. I must meet the regulatory needs of the manufacturers while still meeting the standards of openness required of an open source project.

The regulatory system consists of three major components: the regulatory module, wireless drivers, and CRDA. Both the regulatory module and wireless drivers are part of the kernel. CRDA exists in userspace and therefore can only communicate with the regulatory module via IPC mechanisms. CRDA is optional and the regulatory system functions without CRDA included. OpenWrt does not use or include CRDA.

This document is intended to supplement the Linux wireless kernel documentation.

Understanding regulatory workflows[edit]

The Linux wifi regulatory system uses "regulatory domains" or "regdomains" for short to manage regulations. A regdomain describes a set of rules that a device must follow in order to comply regulations in a given area. Each country has its own regulatory domain as well as a world domain. Once the regulatory core has a regdomain, it may modify the rules for internal use in certain limited circumstances. In those cases, we would still refer to the rules in the core as a regdomain but it's not identical with the domain as originally set.

A request to modify the regdomain of the core is called a "hint" because it usually won't fully replace the current regdomain. As an example, let's say a user says they are in the US and the core regdomain is set to that of another country, say Germany. The core, in most cases, will not simply replace the core regdomain with the regdomain with the United States. Instead, the core regdomain will be set with a regdomain consisting of the intersection of the Germany regdomain and the US regdomain. Additionally, it's possible for a hint to be ignored and to have no change occur such as when a user hint is received and a driver already has indicated they are self-managing their regulatory support.

The regulatory system uses the regdomain to decide which channels are available to the wifi system. If a channel isn't allowed by the regdomain, it will be marked as such and won't be available for use. If a wireless adapter is currently using a channel when it's marked as not allowed, the channel will be force disconnected (after a one minute period to allow the user to change channels).

Regulatory functions[edit]

One way to understand the workflow of the regulatory system is to explore the functions and in the kernel and CRDA. Linux Wifi regulatory functions documents significant functions used by the regulatory system.

Workflow diagrams[edit]

A number of diagrams are created for understanding the flow of functions and files as it handles regulatory hints (NOTE: if you click through to the original SVGs, the function objects in the diagram link to the relevant function documentation in Linux Wifi regulatory functions)

Initializating the regulatory system[edit]

Initializing Regulatory Module.svg

CRDA providing domain information[edit]

CRDA Providing Domain information.svg