Low Level API Use Cases
The primary focus is the control interface to radio and access point functionality, with STA (client) functionality as a lower priority. The data path is generally not a problem, as all known existing drivers model this as a Linux Ethernet device.Availability of source code, and the license of, the device driver, microcode, and any firmware on an embedded offloaded processor, are out of scope.The operating system scope is limited to Linux.
A lack of common interfaces for WLAN has a negative effect on all involved parties. Open source OpenWrt (or other open source router platform) developers are locked out from the use of officially supported drivers, which restricts which silicon solutions they can support. Router middleware vendors find themselves designing their own HAL's, and maintaining several implementations. WLAN is noted by middleware vendors as one of the most complex layers to maintain across chipset SDKs and even across versions of the same SDK.
While SDK users struggle with the lack of a common WLAN API, silicon vendors also maintain multiple interfaces. Those that support OpenWrt develop and maintain their own interface layer. Those that support RDK-B face the same effort with the RDK-B HAL. Those that support other stacks, e.g. their own proprietary one, maintain yet another.
All parties can benefit from a commonly agreed upon interface. More devices supported by OpenWrt benefits the project’s growth. Silicon vendors would only need to support a single interface for all Linux-based devices. Middleware vendors will still need some higher level management software, but the responsibility of the maintenance of the layer between this and the common API will be moved firmly to the middleware vendor. In addition, only one such implementation is needed. For example, a single RDK-B HAL implementation would support all drivers, and therefore, the silicon vendors would not need to maintain a HAL implementation for their chips.
The prpl Carrier Interest Group evaluated the Linux WLAN space and formally recommends the creation and use of drivers based on cfg80211. Cfg80211 is actively maintained by the Linux kernel community and technically and functionally vastly superior to the older ioctl-based wireless interfaces. Additional background on the reason for the kernel community’s move from ioctl interfaces to cfg80211/nl80211 can be found at: http://linuxwireless.org/attachments/en/developers/Documentation/cfg80211/control.pdf. Members of prpl Foundation are strongly encouraged to work with the Linux Wireless community to add missing features into cfg80211, especially features which could be used across multiple vendor implementations.
The standard WLAN driver delivery should include the cfg80211 management API. In the event that the driver is part of a board support package (BSP) for a SoC, the included Linux kernel should have cfg80211 enabled, as should the WLAN driver. The use of the cfg80211 by higher level management software, that may be included in the BSP, is recommended.In addition to cfg80211 drivers, the Carrier Interest Group recommends the use of hostapd, wpa_supplicant and iw connected to the driver via nl80211. In particular, WLAN management frames should be transmitted between the driver and hostapd/wpa_supplicant/iw via nl80211.
Vendor-specific extensions should be limited to hardware or implementation specific functionality that is distinctly not present in cfg80211, and does not lend itself to an extension of cfg80211 either. Examples are control of embedded firmware, debugging interfaces to the lower layers of the implementation, and special calibration logic. Any interfaces that must be used by an operational control interface should be standardized. The recommended interface for vendor-specific extensions is cfg80211 vendor commands.
- cfg80211 driver for WLAN
- iw support with WLAN management frames transmitted via nl80211