Packet Filter Control

To support tethering, your target system must enable packet filtering in the QNX networking stack (io-pkt-*) and launch the pfctl utility to communicate with this service.

The main use case is for Mobile Hotspot, where packet filtering is used to bridge the Wi-Fi Access Point (AP) interface to a WAN connection, either ethernet or cellular. The interface used for bridging is the one with the highest priority in net_pps.

Required services for packet filtering

Typically, the io-pkt-* service is started during bootup. Detailed information on the command line syntax, including how to start specific drivers and load modules, is given in the io-pkt-* entry in the Utilities Reference. To enable packet filtering in the QNX networking stack, you must load the module that handles IP filtering using mount:

mount -Tio-pkt /lib/dll/lsm-pf-*.so

Note: The module file to load depends on the version of the stack you're using:

lsm-pf-v4.so with io-pkt-v4-hc
lsm-pf-v6.so with io-pkt-v6-hc

The stack then creates a device, /dev/pf, that the pfctl utility can use to interact with the packet filter service. You should use waitfor to wait until the device path exists before launching pfctl:

waitfor /dev/pf;
pfctl -e -f /etc/pf.conf

With pfctl, you must use the -e option to enable the packet filter and -f to name the configuration file that contains the rules that support tethering.

You should put the above command sequence in your startup script, after the command that starts io-pkt-*.

For more details on the packet filter client utility and the device that it controls, see the pf, /etc/pf.conf, and pfctl entries in the Utilities Reference.

Configuration file content for supporting tethering

After installing the Networking Middleware package, you must either rename pf.conf.tetherman to pf.conf (and hence, replace the existing file in your QNX SDP installation), or merge the contents of this file from the package into the existing pf.conf file. The first option is useful for the out-of-box experience, when you don't have an existing target image with a customized pf.conf file. The second option is useful for integrating wireless networking into an existing system, because you will pick up the tetherman filtering rules while keeping any existing rules needed for your system.

The required filtering rules entail creating network address translation and packet redirect anchors for tetherman as follows:

# Anchor for tetherman
rdr-anchor "tethering"
nat-anchor "tethering"