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:
- net_pps
- 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.
- tetherman
- 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 connection to use that latter connection
as the backhaul.
- The tetherman service is launched at startup if Access Point 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.
- wpa_pps
- 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.
- 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 (e.g., supported command-line options) 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:
- dhcpd
- 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.
- dhclient
- 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.
- hostapd
- 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 when the target system is in Access Point mode, and must be specified in an option on the
wpa_pps command line. For generic details 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.
- pfctl
- 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.
- pps
- 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., devnp-ti18xx_imx6x.so)
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.
- rtsold
- 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.
- wpa_supplicant
- Implements the Wi-Fi Protected Access (WPA) client and IEEE 802.1X supplicant.
This service 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:
- Launch pps with the configuration file from the package (pps.conf).
- 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).
- Mount the packet filter module and launch pfctl with a configuration file that contains
the rules that enable tethering.
- 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/service-wifi-bcm4359.sh
- ${QNX_TARGET}/scripts/service-wifi-marvell8897.sh
- ${QNX_TARGET}/scripts/service-wifi-tiwl18xx.sh
where
QNX_TARGET is the directory that stores the target backends
within the QNX SDP 7 installation on your host machine.