Overview

The io-pkt utility (io-pkt-v4-hc and io-pkt-v6-hc) is the QNX Neutrino network manager. This is a process outside of the kernel space and executes in the application space. Along with providing the network manager framework, it also includes TCP/IP (TCP, UDP, IPv4, IPv6) support, along with PPP services and a variety of other services built in. DLLs can also be mounted to extend this process's functionality. We provide the following variants of io-pkt:

io-pkt-v4-hc: IPv4 version of the stack.
io-pkt-v6-hc: IPv6 version of the stack (includes IPv4 as part of v6).

Both variants have full encryption and Wi-Fi capability built in and include hardware-accelerated cryptography capability (Fast IPsec).

Included services: UDP, TCP, PPP, BPF, TUN, TAP, IPSec, HW crypto offload
Loadable modules: Qnet, PF, SLIP

Note: In this guide, we use “io-pkt” to refer to all the stack variants. When you start the stack, use the appropriate variant (io-pkt isn't a symbolic link to any of them).

For details about options, see the entry for io-pkt in the Utilities Reference.

You can dynamically load drivers in the following ways:

when starting io-pkt:
```
io-pkt-v4-hc -d name_or_full_path_of_driver_binary [option,[option,..]] [-d ....]
  
```
where name is the unique part of the driver file name (for example speedo vs devnp-speedo.so). Specify each unique driver instance (different option set or different driver) with another -d driver option on the command line.

when io-pkt is running:

mount -T io-pkt [-o option[,option,...]] full_path_of_driver

By default, driver interfaces are sequentially numbered with a name according to the driver type (e.g., fxp0 is the interface for an Intel 10/100 driver). You can use the name= driver option (processed by io-pkt) to specify the interface name.

Drivers don't present entries in the name space to be directly opened and accessed with a devctl() command. Instead, a socket file descriptor is opened and queried for interface information. The ioctl() command is then sent to the stack using this device information.

Because there's no entry for a driver in the name space, you can't use umount to unmount it. To unload a driver DLL (if the driver supports it), use ifconfig:

ifconfig interface_name destroy

Once all the interfaces managed by a driver have been destroyed, the driver DLL is unloaded, unless there are special actions taken by the driver to stay resident.

We've designed io-pkt to follow as closely as possible the NetBSD networking stack code base and architecture. This provides an optimal path between the IP protocol and drivers, tightly integrating the IP layer with the rest of the stack. The io-pkt implementation includes the following features:

You can mount protocols and enhanced stack functionality (e.g., TDP, NAT / IP Filtering), but you can't unmount them.
IP Filtering and NAT are handled through the PF interface with pfctl.

In io-pkt loopback-checksumming is controlled via sysctl:

# sysctl -a | grep do_loopback_cksum
net.inet.ip.do_loopback_cksum = 0
net.inet.tcp.do_loopback_cksum = 0
net.inet.udp.do_loopback_cksum = 0

It's possible to launch more than one instance of io-pkt (see its entry in the Utilities Reference). This ability is limited only by the management of the hardware interfaces, as typically only one driver instance (in one io-pkt instance) would manage one hardware interface.