Deployment Model

There are several Networking Middleware processes and QNX Neutrino services that work together to support networking and Wi-Fi management.

The Networking Middleware processes are part of a runtime component called net.middleware. This component interacts with the QNX Neutrino RTOS as illustrated here:

Figure 1. Networking Middleware Process Deployment
The Networking Middleware processes perform the following functions:
Offers a PPS interface for communicating with the QNX networking stack (io-pkt-*). For general information about QNX support for networking, see the Networking Architecture chapter in the System Architecture guide. The net_pps service controls network interfaces and publishes their statuses and interface availability details.
The Network Manager component in the libqwf_interface library provides a C API wrapper for net_pps. This gives applications an interface that's independent of the underlying interprocess communication (IPC) mechanism, but the net_pps service must be running for Network Manager API calls to have any effect.
Information on how to run the service (e.g., supported command-line options) is given in the net_pps entry in the Networking Middleware Services Reference.
Allows one networking connection to be bound (tethered) to another connection. This service is required for the target system to act as a Wi-Fi access point or Mobile HotSpot (MHS). The common use case is tethering a Wi-Fi MHS connection to an ethernet or a cellular connection, and using that latter connection as the backhaul.
The tetherman service is launched at startup if Access Point (AP) mode is needed. When the client starts the Wi-Fi MHS through the C API, the service dynamically configures the RDR and NAT tethering anchors located in the packet filter configuration file. This is explained in detail in the Networking Middleware Services Reference.
Offers a PPS interface for configuring Wi-Fi Protected Access (WPA) connections. The wpa_pps service allows clients to manage Wi-Fi connections and Wi-Fi station profiles, through operations such as configuration, persistence, blacklisting, and more. It talks to wpa_supplicant for STA (station, or client) mode and hostapd for AP mode.
The Wi-Fi Manager component in the library provides a C API wrapper for wpa_pps. This gives applications an interface that's independent of the underlying IPC mechanism, but the wpa_pps service must be running for Wi-Fi Manager API calls to have any effect.
Information on how to run the service is given in the wpa_pps entry in the Networking Middleware Services Reference.
The QNX Neutrino processes perform supporting functions. Not all OS processes required for wireless networking are shown in Figure 1; this is to keep the deployment diagram simple and readable. Here, we explain the roles of all of these services:
Used by tetherman to assign dynamic IP addresses to MHS clients, when the target system is configured for Access Point mode. For details on this networking service, see the dhcpd, dhcpd.conf, dhcpd-dhcpv6.conf, and dhcpd.leases, dhcpd6.leases entries in the Utilities Reference.
Used by wpa_pps to request IP addresses when connected in Station mode to a Wi-Fi access point. The dhclient service is actually launched by net_pps, because this latter service must manage the Wi-Fi station (i.e., client) interface. For more information, see the dhclient, dhclient-script, dhclient.conf, dhclient-dhcpv6.conf, and dhclient.leases, dhclient6.leases entries in the Utilities Reference.
Acts an authenticator for IEEE 802.11 networks, offering full support for WPA/IEEE 802.11i. The hostapd binary is delivered with the driver and is specific to the Wi-Fi chipset.
This utility is used indirectly by tetherman to enable MHS AP mode, and must be specified in an option on the wpa_pps command line. For information on this utility, see the hostapd-version entry in the Utilities Reference.
io-pkt-v4-hc or io-pkt-v6-hc
Implements the TCP/IP stack and handles packets that transport wireless data. QNX Neutrino supports IPv4 and IPv6 over ethernet, Wi-Fi, and cellular.
Note: For tethering to work, all interfaces to be tethered, along with the packet filter utility, must be mounted in the same io-pkt-* instance. Interfaces mounted to different io-pkt-* instances cannot be bridged.
For full details on the stack service, see the io-pkt-* entry in the Utilities Reference.
Used by tetherman to communicate with io-pkt-* to bridge a Wi-Fi interface to an ethernet interface, as part of a hotspot. The commands and configuration file contents needed to start and configure this networking service for usage by tetherman are explained in the Packet Filter control topic in the Networking Middleware Services Reference.
Manages the Persistent Publish/Subscribe (PPS) system, which provides an IPC method based on filesystem objects. The Network Manager and Wi-Fi Manager components in the libqwf_interface library use PPS to talk to net_pps and wpa_pps. Full details on the PPS system are provided in the Persistent Publish/Subscribe Developer's Guide.
QNX Hardware Drivers
Interact with low-level modules that support specific wireless connection types. These drivers are loaded by the io-pkt-* stack service.
A Secure Digital Input Output (SDIO) driver (e.g., can support Wi-Fi connections by providing an SDIO interface to connect Wi-Fi modules to a host processor. However, Wi-Fi modules can use other interfaces, such as PCI Express or UARTs, for communication and control.
Used by net_pps for IPv6 configuration. Because rtsold must be running even if IPv6 addressing isn't required, net_pps launches this router solicitation daemon at startup. For more details on what it does, see the rtsold entry in the Utilities Reference.
Implements the Wi-Fi Protected Access (WPA) client and IEEE 802.1X supplicant. This service supports both STA (station, or client) mode, and P2P mode. Specifically, it handles WPA key negotiation with a WPA Authenticator and EAP authentication with Authentication Server. It also controls the roaming, and authentication and association of the WLAN driver.
The utility is configured using a text file that lists all accepted networks and security policies. After the device has been configured, higher-level configuration such as DHCP may proceed. The configuration of WPA Supplicant and how it can be integrated into networking scripts is explained in the wpa_supplicant entry in the Utilities Reference.
There may be a driver-specific version of this utility (e.g., /usr/sbin/wpa_supplicant_ti18xx for TI WiLink 8). Examples of command lines for starting this service are given in the wpa_supplicant entry in the Networking Middleware Services Reference.

Launch order for wireless networking services

To enable wireless networking on your target system, you must launch the services described above in a certain order at startup. This means that your target image must contain the library files and utilities from the Networking Middleware package, at the right locations. For instructions on building an image with the required files, contact QNX Customer Support. Here, we list the main tasks needed to enable wireless networking, which are:
  1. Launch pps with the configuration file from the package using the command pps -A /etc/pps.conf. The pps.conf file delivered in the networking package contains the information needed to set up the PPS folders used by the networking services.
  2. When the /pps path appears, launch net_pps with a minimum set of managed interfaces containing the Wi-Fi station interface and the ethernet interface (to be used for tethering). Refer to the net_pps command-line options for the proper startup of this service.

    You must ensure that your image contains the net_pps.conf file. This file can be empty, but will need to exist in the image. The default location is /etc/.

  3. For tethering operation, mount the packet filter module and launch pfctl with a configuration file that contains the rules that enable tethering.
  4. Start wireless services by mounting the Wi-Fi driver and running wpa_supplicant, wpa_pps, and (possibly) tetherman.
The exact steps required for the last task depend on the Wi-Fi module used, so it's best to do them in a dedicated, platform-specific script. The Networking Middleware package contains sample scripts that enable or disable Wi-Fi on particular platforms. These scripts are unpackaged at the following paths:
  • ${QNX_TARGET}/scripts/
  • ${QNX_TARGET}/scripts/
where QNX_TARGET is the directory that stores the target backends within the QNX SDP installation on your host machine.