What's new in the networking stack?

The QNX Neutrino networking stack is called io-pkt. It replaces the previous generation of the stack, io-net, and provides the following benefits:

performance improvements. Since io-pkt removes the npkt-to-mbuf translation and mandatory queuing, and also reduces context switching on the packet receive path, the IP receive performance is greatly improved.
simplified locking of shared resources, resulting in simpler SMP support
it closely follows the NetBSD code base and architecture, meaning:
- easier maintenance / upgrade capability of IP stack source
- existing applications that use BSD standard APIs will port more easily (e.g. tcpdump )
- enhanced features included with NetBSD stack are also included with io-pkt
- NetBSD drivers will port in a straightforward manner
far richer stack feature set, drawing on the latest in improvements from the NetBSD code base
802.11 Wi-Fi client and access point capability

The io-pkt manager is intended to be a drop-in replacement for io-net for those people who are dealing with the stack from an outside application point of view. It includes stack variants, associated utilities, protocols, libraries and drivers.

The stack variants are:

io-pkt-v4

IPv4 version of the stack with no encryption or Wi-Fi capability built in. This is a "reduced footprint" version of the stack that doesn't support the following:

IPv6
Crypto / IPSec
802.11 a/b/g Wi-Fi
Bridging
GRE / GRF
Multicast routing
Multipoint PPP

io-pkt-v4-hc

IPv4 version of the stack that has full encryption and Wi-Fi capability built in and includes hardware-accelerated cryptography capability (Fast IPsec).

io-pkt-v6-hc

IPv6 version of the stack (includes IPv4 as part of v6) that has full encryption and Wi-Fi capability, also with hardware-accelerated cryptography.

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).

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.

Note: The io-pkt stack isn't backward-compatible with io-net. However, both can exist on the same system. For more information, see the Migrating from io-net appendix in this guide.

The io-pkt implementation makes significant changes to the QNX Neutrino stack architecture, including the following:

io-net is replaced by the stack's link layer
mbufs are used throughout, including in the drivers
all buffer management is handled by the stack
mount and umount capabilities:
- Only io-net drivers may be both mounted and unmounted. Other drivers may allow you to detach the driver from the stack, by using the ifconfig iface destroy command (if the driver supports it).
- The IP stack is an integral part of io-pkt; you can't start io-pkt without it. This means that you don't need to specify the -ptcpip option to the stack unless there are additional parameters (e.g. prefix=) that you need to pass to it. If you specify the -ptcpip option without additional parameters, io-pkt accepts it with no effect.
- Protocols and enhanced stack functionality (e.g. TDP, NAT / IP Filtering) can be mounted, but not unmounted.
The concepts of producers and consumers no longer exist within io-pkt. Filters still exist, but they use a different API than with io-net. The io-pkt stack does provide other hooks into the stack that you can use to provide a similar level of functionality. These include:

Berkeley Packet Filter interface

Lets you read and write, but not modify or discard, both IP and Ethernet packets from your application.

Packet Filter interface

pfil hooks, enabled when the PF filter module is loaded, let you read, write, and modify IP and Ethernet packets within the context of the stack process.
Driver changes:
- The driver model has changed to provide better integration with the protocol stack. (For example, in io-net, npkts had to be converted into mbufs for use with the stack. In io-pkt, mbufs are used throughout.)
- The driver API and behavior have been changed to closely match those of the NetBSD stack, allowing NetBSD drivers to be ported to io-pkt.
- A shim layer, devnp-shim.so, is provided that lets you use an io-net driver as-is.
- By default, driver interfaces are no longer sequentially numbered with en x designations; they're named according to 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 no longer present entries in the name space to be directly opened and accessed with a devctl() command (e.g. open(/dev/io-net/en0)). 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.
IP Filtering and NAT are now handled through the PF interface with pfctl . This replaces the io-net ipf interface, which is no longer supported.
SCTP isn't supported in the initial release of io-pkt.

In io-net, loopback-checksumming was done with ifconfig. In io-pkt this 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

The nicinfo utility operates slightly differently from the way it did under io-net:
- The default operation with no arguments is to list information on all interfaces. The behavior with io-net was to show stats for /dev/io-net/en0.
- Under io-net, all Ethernet interface names were in the form en X. Under io-pkt, this name will vary, but you can use the name= driver option (processed by io-pkt) to override this.
- Ported NetBSD drivers might not support the nicinfo ioctl() command.