[Previous] [Contents] [Index] [Next]


Native QNX Neutrino network manager -- backward-compatible version


io-net ... -p qnet [option[,option]...]


Note: This manager is going to be deprecated in future editions. It's currently included because it's compatible with QNX Neutrino 6.2.

Use commas (,) to separate the options (not spaces).

Overwrite Qnet's misaligned-access detection. The value of X is one of:
Don't allow misaligned access.
Allow misaligned access.
Encapsulate the Qnet packet into an ip or ethernet packet. By default, Qnet uses bind=en. If you specify a full interface name (e.g. bind=en0), then only that interface is used.
Change the hostname of the machine.
Map any incoming user ID to map_uid and map its group ID to the group ID of map_uid.
If the incoming user ID is 0, map it to map_uid and map its group ID to the group ID of map_uid.
A network directory. The default directory is /net. The default domain is either the hostname domain, if it has one, or the directory with the slashes changed to dots and reversed. For example, /net/outside/canada has a domain of canada.outside.net. The first mount is the default directory and domain that the local hostname will resolve to.
Add n padding bytes between the link layer header and the Qnet packet header, to make the packet (and its payload) aligned. All nodes in the network running npm-qnet-compat.so must specify the same option argument in order to communicate. Default is no padding (padding=0).
Add to the resolver list for mountpoints that follow.

The following values for resolver are built into the network manager:

If you specify something else for resolver, Qnet attempts to load nr-resolver.so. The default name resolver is ndp. For queries how to create nr-resolver.so, please contact QNX support.


The npm-qnet-compat.so interface implements native QNX Neutrino networking. It's the original Qnet stack.

If you want to use this version of Qnet, make /lib/dll/npm-qnet.so a symbolic link to npm-qnet-compat.so. By default, npm-qnet.so is a symbolic link to npm-qnet-l4_lite.so.

Note: When you specify two or more resolve= options in a series, the resolvers form a list of lookups for the directory specified in the subsequent mount= options.

You may notice that the list of resolvers is terminated by a mount= option. Any resolve= options placed after a mount= option form a new list -- they don't add to the previous list.

For example, the following line:


specifies that:

has resolvers a and b
also has resolvers a and b
has only resolver c.


If this file exists, your system is using the default startup files, and io-net is running when your system starts up, the system automatically loads the Qnet module that /lib/dll/npm-qnet.so points to (npm-qnet-l4_lite.so by default). For more information, see the Controlling How Neutrino Starts chapter of the Neutrino User's Guide.


Qnet doesn't support networking processors of different endianness. If you need cross-endian file access, consider using NFS.

Don't use the options bind=en and resolve=dns together; that combination is invalid.

See also:

io-net, npm-qnet.so, npm-qnet-l4_lite.so

"Network drivers (devn-*)" and "Network protocol modules (npm-*)" in the Utilities Summary

Using Qnet for Transparent Distributed Processing in the Neutrino User's Guide

Native Networking (Qnet) in System Architecture

Transparent Distributed Processing Using Qnet in the Neutrino Programmer's Guide

[Previous] [Contents] [Index] [Next]