Linux Wireless

nl80211 is the new 802.11 netlink interface public header. Together with cfg80211 it is intended to replace Wireless-Extensions. nl80211 and cfg80211 are still under development.

Current users of nl80211:

• iw
• crda
• hostapd
• wpa_supplicant (with -Dnl80211)
• iwd
• NetworkManager (scanning etc.)

OpenWrt folks created a tiny version of libnl based on a git snapshot, which only contains genl, not rtnetlink or any of the netfilter stuff, and compiles down to less than 30k in binary size. You can find it here:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=package/libs/libnl-tiny;hb=HEAD

include/uapi/linux/nl80211.h

The nl80211 testmode command helps implementing things like factory calibration or validation tools for wireless chips.

This functionality could possibly be used for SAR testing (Specific Absorption Rate), MPE testing (Maximum Permissible Exposure), RF testing (Radio Frequency), as possibly requested by institutions such as FCC.

According to kernelnewbies.org Linux_2_6_32, testmode has been introduced by nicely described commit aff89a9b90849.

This setting is currently provided by net/wireless/Kconfig.

For a way to determine whether a wireless driver actually supports nl80211 testmode interface, see [PATCH] nl80211: add testmode to the list of supported commands.

Current users of the testmode interface are:

• wl12xx calibrator (chipsets WL1271 etc.)

TODO: could list (references to) ready-made scripts which implement nicely automated / elegant workflows for SAR testing etc.

For ATH9K chipsets, there's SAR testing functionality provided via the non-testmode setting CONFIG_ATH9K_TX99. Hmm, this possibly needs conversion to (additionally?) providing the generic nl80211 testmode functionality?

Under the NL80211_CMD_VENDOR command, there's the ability to register vendor-specific behavior. For a long time, we've explicitly rejected these upstream, but after many discussions some may be allowed, subject to (at least) the following constraints:

1. Upstream vendor commands shall not replace existing functionality.
2. The submitter shall consider a pure nl80211 implementation and explain the reasoning against it in the commit message.
3. Example users/use cases of the API shall be documented.
4. The newly proposed API shall be subject to stable API rules.
5. The content of the NL80211_ATTR_VENDOR_DATA shall be documented.
6. Vendor command and sub-attribute definitions shall be in a common header file location (TBD, e.g. include/uapi/nl80211-vnd-*.h)
7. Patches introducing such commands shall be submitted separately, not “buried” in big driver patchsets. Give them a “nl80211: vendor-cmd: ” prefix to make them easily identifiable.

The goal with these rules is to enable use of vendor commands in a fashion that is transparent enough to allow later reuse by other components with similar needs, and then potentially defining “real” nl80211 API for the use case in question.

Patches will be merged through Kalle Valo's tree, but should also be reviewed by Johannes (cfg80211 maintainer).