Premium WiFi Advantage Software

Being wireless experts is a full-time job – and we’ve seen it all. Under our roof are decades of experience that address every single step of hardware and software development, with capabilities and support our competitors can’t touch. We’re a collection of experienced hardware designers, full EMC and regulatory technicians, customer-first software designers, and a global support organization ready to get into the weeds to get your product to market.

icon-wifi-advantage-software.png

Linux Foundation Member

icon-software-linux.png

Ezurio (formerly Laird Connectivity) Stack Advantage

The core of our software advantage is the Wi-Fi connectivity stack for Linux and Android we provide and support for our Wi-Fi + Bluetooth certified modules. Utilizing the core software structure and stack components that make up the Linux Wi-Fi and Bluetooth connectivity stack, we leverage its expertise and QA capabilities to expand upon the usual deliverable for a Wi-Fi + Bluetooth combination radio.

Value Advantage Ezurio Comments
QA Tested Linux Connectivity Stack x Tested against multiple Linux kernel versions and board support package versions 
Supports Multiple Kernel Versions x Backports tested to deliver known good builds against older kernel versions
Provides Flexible Build Environment Options x Supports Buildroot, Yocto, Android, and Ubuntu
Maintained Curated Connectivity Stack Source Code x Constantly maintained to the latest driver source and kernel components

Connectivity Stack

icon-software-backport.png

Ezurio Linux Stack

The structure of the Linux connectivity stack and its components are shown in the figure below. As you can see we deliver several components in the stack targeted at providing the most reliable and highest performing connectivity option available. Most certified module suppliers will only provide a minimal set of components that are directly linked to their hardware solution and require the developer to integrate these with the rest of the stack. As the connectivity stack diagram shows, there are many interactions between the components and making sure the device specific components work together with the rest of the stack can take time and effort.

Wi-Fi-Value-Prop-Stack-Image1.png

We provide a broader selection of components to reduce the chance of incompatibility and create a simpler and faster integration of the device specific components by pretesting and QA-ing the full stack with the device specific software and those components they interact with. The result is a set of software components in the connectivity stack that have previously been tested and confirmed to build before you even see them. A comparison of the tested and supplied connectivity components vs. our competition can be seen here:

Wi-Fi Connectivity Stack Component Mainline Linux Ezurio QA Competitor
Radio Firmware Device specific binary, containing operational code for radio baseband and transceiver components. Includes operational code and device configuration data for regulatory and IEEE802.11 and Bluetooth compliance. x x x
Radio Interface Driver Device driver that provides operation of the hardware interface between the host and the radio. x x
Wi-Fi Radio Device Driver Device driver the handles the interaction between the Linux connectivity stack and the Wi-Fi radio firmware x x x
Bluetooth Radio Device Driver Device driver the handles the interaction between the Linux connectivity stack and the Bluetooth radio firmware. x
mac80211 802.11 MAC implementation in the Linux kernel For Wi-Fi radios that rely on the host for an 802.11 packet create and state machine. x x
cfg802.11 Netlink based configuration API for 802.11 devices in Linux. It bridges user space and drivers and offers some utility functionality associated with 802.11. cfg80211 mustbe used by all modern Wi-Fi drivers in Linux, so that they offer a consistent API through nl80211. x x
Network Stack The network stack allows the application to communicate with the physical network devices. The network stack is divided into multiple layers. There are different network layers. x
BlueZ (net/bluetooth) Kernel portion of the BlueZ stack. x x
Socket/bind/etc. syscalls An important network data-transfer mechanism used to build networked applications, implement protocols and provide network services. x
Ioctl calls on socket fds An ioctl call controls various driver options like handling of special characters, or the output signals on the port (such as the DTR signal). x
Netlink Socket Network-related tasks such as routing, firewalling, and traffic control. Netlink sockets use a standardized communication protocol that allows for the exchange of messages between the kernel and user-space processes. x
CRDA/Regulatory Application Acts as the udev helper for communication between the kernel and user space for regulatory compliance. x x
BlueZ (bluetoothd) User space portion of the BlueZ stack x x
ifconfig Deprecated tool use on legacy Linux system is used to assign an address to a network interface and to configure or display the current network interface configuration information. x
Iwconfig Deprecated tool used on legacy Linux system is used to display and change the parameters of the Wi-Fi network interface which are specific to the wireless operation (e.g. interface name, frequency, SSID). It may also be used to display the wireless statistics. x
Iw Modern Linux tool used to do basic command line Wi-Fi operations such as distinguish between the hardware (also called phy) and the interface (also called dev), and display and change the parameters of the network interface which are specific to the wireless operation (e.g. interface name, frequency, SSID). x
WPA_Supplicant It implements key negotiation with a WPA authenticator and it controls aspects of IEEE 802.11 client, P2P, and AP operations including roaming and IEEE 802.11 authentication/association of the wireless driver. x x
Dhcp Client A Dynamic Host Configuration Protocol (DHCP) client requests the dynamic IP address and corresponding configuration information from a DHCP server each time a client connects to the network. x
Ifup/ifdown Scripts Common embedded tools for bringing the network interface up or down, allowing it to transmit and receive data or place the network interface in a state where it cannot transmit or receive data. x
Network Manager Daemon (NetworkManager) A system network service that manages your network devices and connections and attempts to keep network connectivity active when available. It manages Ethernet, Wi-Fi, mobile broadband (WWAN), and PPP devices, VPN services, and other common networking functionality in Linux.  x x
GUI Apps for Network Admin Graphical User Interface (GUI) applications that provide an interface for the configuration of the network interface and network manager. x
Application Using Network A user application that includes connectivity functionality to be available for the transfer of data between the system and a network. x
Application Using Bluetooth A user application that includes connectivity functionality to be available for the transfer of data between the system and a Bluetooth network or device. x

Since we utilize the standard Linux Wi-Fi connectivity stack architecture and software components, it is possible to selectively use the provided files provided in our Ezurio Stack package. However, this must be done with caution and the understanding that we cannot guarantee the resulting stack will build or perform correctly. We also will not directly support any integrations that do not utilize our entire stack, this is due to the fact we have no knowledge of the components being used.

Our connectivity stack is fully supported by our support team. So if you have any issues building or getting your code to operate as expected, we can provide direct technical support to make sure your system is operational as soon as possible.

Extensively QA Tested

icon-software-testing.png

Linux Kernel Backports Package

As part of our connectivity stack we utilize the Linux kernel backports project. This allows Ezurio to provide not just a single known supported kernel for our radios, but a range that covers the most widely used variants. This extends the simplicity of integration that the stack provides beyond just a single instance and allows you build functional code very quickly even if you are not using the latest kernel version.

We support kernel versions as early as v2.6.37 and maintain options through the latest long-term support versions being used by the industries to most popular MPU SDK packages. There are over 60 kernel versions supported in the backports package, not all kernel versions are supported by all radios. The currently supported kernels, by radio, can be seen in table below.

Product Kernel Version
v3.2 v4.1 v5.1 v5.10 v6.1 v6.16
LWB x x x x
LWB5 x x x x
LWB+ x x x x
LWB5+ x x x x
60 Series x x x x x

*Kernel versions back to v2.6 available. Multiple kernel version are supported between those indicated.

Since our connectivity stack is maintained constantly and gets the benefits of bi-annual updates each year (more if there are security or feature adds), the table will have been extended and it is recommended you check with your support contact to get the latest support profile.

Additionally, we have the ability to support kernel version outside of those listed above. This includes vendor Linux kernels and Android release versions.

wpa_supplicant

One of the advantages of testing this important component of the connectivity stack, directly linked to the supported security provided by the Wi-Fi radio, is that we can extend and confirm operation for a broad set of security options. These include the support for Enterprise security, the EAP types, certificate length and cypher types.

The following table outlines how our security type support compares with some of our competitors:

Capability LWB LWB5 LWB+ LWB5+ IF573 60 Series Competitor
WPA2 Home x x x x x x x
WPA2 Enterprise x x x x x x x
WPA3 Home x x x x x
WPA3 Personal Transition x x x
WPA3 Enterprise Transition x x x
WPA3 Enterprise x x x x
WPA2 / WPA3 EAP Types EAP-FAST
EAP-TLS
EAP-TTLA
PEAP-MSCHAPv2
PEAP-GTC
PEAP-TLS
LEAP
EAP-TLS
EAP-TTLA
PEAP-MSCHAPv2
PEAP-GTC
PEAP-TLS
LEAP
WPA2 / WPA3 Cert Sizes RSA 4096 bit RSA 4096 bit
WPA2 / WPA3 Cyphers Supported CCMP-128 BIP-CMAC-128 CCMP-128 BIP-CMAC-128

Without this work the effort to get the components and security features enabled can be large. It also means we can extend the supported set as security demands change and customers require updated and extended security support.

Engineering Team

icon-software-features.png

Feature Performance

Our investment into producing the highest quality product is reflected in the performance, breadth of features we can provide. The following highlights these benefits:

Station Security Mode Support

LWB+ LWB5+
Security Mode AKM Suite AKM Description Cipher Supported EAP Type(s) Supported EAP Type(s)
WPA2 Enterprise 00-0F-AC:1 802.1x CCMP-128 x All x All
WPA2 Personal 00-0F-AC:2 and 00-0F-AC:6 PSK and PSK-SHA256 CCMP-128 x x
WPA2 Enterprise FT (Fast BSS Transition) 00-0F-AC:3 802.1x FT CCMP-128 x All
WPA2 Personal FT (Fast BSS Transition) 00-0F-AC:4 PSK FT CCMP-128 x
WPA3 Enterprise Transition 00-0F-AC:1 and 00-0F-AC:5 802.1x and 802.1x-SHA256 CCMP-128 x All x All
WPA3 Enterprise 00-0F-AC:5 802.1x-SHA256 CCMP-128 x All x All
WPA3 Personal Transition 00-0F-AC:2, 00-0F-AC:6 and 00-0F-AC:8 PSK, PSK-SHA256, SAE (SHA256) CCMP-128 x x
WPA3 Personal 00-0F-AC:8 SAE (SHA256) CCMP-128 x x
00-0F-AC:11 802.1x Suite B EC 256 GCMP-128/BIP-GMAC-128
WPA3 Enterprise 192-Bit 00-0F-AC:12 802.1x Suite B 192 EC 384 GCMP-256/BIP-GMAC-256 (WPA3)
CCMP-256/BIP-CMAC-256/BIP-GMAC-256 (WPA2)
00-0F-AC:13 802.1x FT EC 384 GCMP-256/BIP-GMAC-256 (WPA3)
CCMP-256/BIP-CMAC-256/BIP-GMAC-256 (WPA2)

AP Security Mode Support

LWB+ LWB5+
Security Mode AKM Suite AKM Description Cipher Supported EAP Type(s) Supported EAP Type(s)
WPA2 Enterprise 00-0F-AC:1 802.1x CCMP-128
x All except LEAP
WPA2 Personal 00-0F-AC:2 or 00-0F-AC:6 PSK or PSK-SHA256 CCMP-128 x x
WPA2 Enterprise Fast BSS Transition 00-0F-AC:3 802.1x FT CCMP-128
WPA2 Personal Fast BSS Transition 00-0F-AC:4 PSK FT CCMP-128
WPA3 Enterprise Transition 00-0F-AC:1 and 00-0F-AC:5 802.1x and 802.1x-SHA256 CCMP-128

WPA3 Enterprise 00-0F-AC:5 802.1x-SHA256 CCMP-128
x All except LEAP
WPA3 Personal Transition 00-0F-AC:2, 00-0F-AC:6 and 00-0F-AC:8 PSK, PSK-SHA256, SAE (SHA256) CCMP-128 x
WPA3 Personal 00-0F-AC:8 SAE (SHA256) CCMP-128 x x
00-0F-AC:11 802.1x Suite B EC 256 GCMP-128/BIP-GMAC-128
WPA3 Enterprise 192-Bit 00-0F-AC:12 802.1x Suite B 192 EC 384 GCMP-256/BIP-GMAC-256 (WPA3)
CCMP-256/BIP-CMAC-256/BIP-GMAC-256 (WPA2)
00-0F-AC:13 802.1x FT EC 384 GCMP-256/BIP-GMAC-256 (WPA3)
CCMP-256/BIP-CMAC-256/BIP-GMAC-256 (WPA2)

AP mode throughput identifies the aggregate average throughput for all clients when the max number of clients are simultaneously passing data. Testing is done on both the 2.4 GHz and 5 GHz bands (if supported) using the maximum link rate. Results are also gathered in both the upstream and downstream direction. The performance test is accomplished using IxChariot software to generate the traffic flows and accumulate the results. The throughput is measured between the IxChariot endpoints installed on the AP and each of the test clients using a standard IxChariot throughput script sending IP traffic. 

AP Mode Data

Benchmark LWB+
CYW43439
LWB5+
CYW4373E
AP Mode Support x x
AP Mode Max Clients Supported 10 8
AP Mode Throughput (Mbps) Aggregate Avg Aggregate Avg
2.4 GHz Upstream (TCP) 23.82 Mbps 16.07 Mbps
2.4 GHz Downstream (TCP) 11.82 Mbps 9.55 Mbps
5 GHz Upstream (TCP) N/A 133.50 Mbps
5 GHz Downstream (TCP) N/A 133.70 Mbps

Delivery and Development

The best software in the world is no use if you cannot get access to it. We have spent a great deal of time making our software accessible and easily integrated. Firstly, we follow the open-source licensing utilized by the Linux.org for software distribution, we require no additional licenses for the standard connectivity stack components. However, there are situations where software necessary for the development and testing of a system could require tools that must be licensed form the supporting silicon vendor, where possible we have developed and support a license free tool for these situations called the Laird Regulatory Utility (LRU), again making access to the necessary components for development as easy as possible. The table below shows some of the highlights:

Benefit Option 1
Ezurio Stack
Option 2
Minim l Driver Support
Option 3
Open Source
Option 4
Closed Source
Open-Source License x x x
Open Web Accessible x x x
Build Root x optional
Ubuntu x optional optional optional
Yocto x optional x optional
Multiple Development Environments x
Maintained x x
Integrated Device Binaries x optional x
License Free Regulatory Tools x
Module Partner Supported x x
Free x x x
Software Release Notes x optional x x
Regulatory Release Notes x

Access to the software is critical and not universal in how it can be achieved; again we have enabled the most flexible and easily accessible access to our connectivity stack. Compared to the options form our competitors, it provides the simplest access and most flexible integration options, especially when combined with the options provided by the connectivity stack.

Comparing some of the approaches available against Ezurio's solution might provide some clarity on why our approach will suite you the best. 

How Do I Get Access to the Radio Software?

There are several ways to provide access to the radio software, some are limited by licensing and other reduce flexibility of integration but let’s look at the options. 

Option 1: Ezurio

This option is how Ezurio enables access to the software. Note the software is freely available on your website, there are multiple development environments supported and the expanded software component availability allows very fast integration and building of the connectivity stack.

We host all our software on Github to allow access to it from your build environment. Having your build system automatically pull the recipes and artifacts required to add our radio module software to your product's image is easy. For Yocto users, add our Yocto Layer hosted on Github which contains the recipes and paths to all our software. For Android users, add our driver and supplicant repositories to your repo manifest, add some minor additions to your Makefiles and init scripts, and do a build to easily add our QAed release versions to Android. For other build systems, all the required software artifacts are hosted via publicly accessible links for easy addition to any build recipe.

Wi-Fi-Value-Prop-Flow-Charts-Option-11.png

Option 2: Minimal Driver Support

This approach does mean there is now a known owner of the source code, although discussions around whether the module provider or the semiconductor manufacturer will own support remain. 

With this approach it is possible to provide development system support e.g. Yocto specifically for the source being provided. Typically, only the build systems supported directly by the semiconductor manufacturer will be supported. This requires you to either change your build system to the one supported or work out how to port the available code into your build system and tool chain.

With this approach it is very likely that no additional testing of the code has been done, except to make sure in a limited configuration the driver will build. Support for multiple kernels and platforms is likely not to exist and therefore porting to your platform will fall on you or require additional effort and delays from the module vendor or 3rd party.

Making sure you have the best radio firmware and necessary regulatory binaries can be challenging as it will depend upon the module manufacturer (or the semiconductor manufacturer) to make sure these are made available for not only the silicon radio but the manufactured module.

Wi-Fi-Value-Prop-Flow-Charts-Option-21.png

Option 3: Mainline

This requires a mainline driver to exist and will then defer ownership of issues and performance to the mainline support community. Although meaning licensing is in-line with the Linux.org licensing requirements, the question of “Where do I go for support?” must be high on the list when looking at this approach, especially when looking at an embedded application.

Often the latest driver source is not used in the mainline connectivity stack, meaning security issues, feature loss, performance and reliability can be issues when using this code.

Making sure you have the latest radio firmware and necessary regulatory binaries can be challenging in this case.

Wi-Fi-Value-Prop-Flow-Charts-Option-31.png

Option 4: Closed Source

This is a common approach used to protect IP and manage development workload. In this case there is likely a cost for access to the source code and potentially a per unit charge for deployment to your market.

Code provided will most likely be delivered as solution crafted for your platform. In most cases, depending upon the work for the module vendor, to provide operational source for your target platform there will be that licensing charge along with a delay as porting work is done to make sure your get functional code.

With this approach, maintenance can be a difficult item as it is likely you will be required to pay for maintenance or updates such as security, feature, or kernel development enabled desirable updates.

Making sure you have the best radio firmware and necessary regulatory binaries should not be an issue in this case.

Wi-Fi-Value-Prop-Flow-Charts-Option-41.png

In options 2 through 4 you are not guaranteed to get anything more than the device driver and associated radio firmware binaries. Integrating the driver source with your Linux distribution, that will have its own Wi-Fi connectivity stack, falls on you. Often driver to supplicant interaction needs significant work to make sure it is fully compatible and meets the operational requirements for your application.

Explore Premium WiFi Advantages