| Updated: April 19, 2023 |
Applications that use io-pkt can be modified to use io-sock. QNX recommends the following initial modifications to make them compatible.
Make sure that all socket libraries reference the io-sock libraries. The LD_LIBRARY_PATH environment variable specifies the paths that the runtime linker uses to search for shared libraries (see “Setting PATH and LD_LIBRARY_PATH” in the QNX Neutrino User's Guide).
Make sure your application references the correct version of libsocket.so. The LIBVPATH macro in the common.mk file allows you to specify directories to search for library files. For example:
LIBVPATH=path_to_libsocket
For applications that use the socket APIs, add references to the io-sock headers before the standard headers. The EXTRA_INCVPATH macro in the common.mk file allows you to specify the location of the io-sock headers. For example:
EXTRA_INCVPATH=path_to_io-sock
You can use the $(USE_ROOT_INCLUDE) environment variable, which sets the default value for INCVPATH. For example:
EXTRA_INCVPATH =$(USE_ROOT_INCLUDE)/io-sock INCVPATH+=$(USE_ROOT_INCLUDE)
For more information about the LIBVPATH, INCVPATH, and EXTRA_INCVPATH macros, see “The common.mk file” in the QNX Neutrino Programmer's Guide.
There is no io-sock version of the libsocket.a static library. Instead, your io-sock applications should link against the io-sock shared library as described above. If your io-sock makefiles reference the libsocket.a static library, the io-pkt static library may be included by mistake. To help you detect links that you need to change, io-sock provides libsocket.a and libsocketS.a files that contain linker script. If your makefile references these files, the build fails but the script that they contain provides a message that explains why it failed and how to fix the issue.
Many of the prerequisite header files that are included in io-pkt header files are not included by io-sock header files. For example, in_var.h requires net/if.h and if_dl.h requires sys/types.h.
For example, to identify binaries that link to libsocket.so.3, execute the following command on the target:
for x in `find . -type f`; do strings $x | grep -q 'libsocket.so.3' && echo $x ; done
Both io-pkt and io-sock use a etc/hosts file for information about known hosts. Unlike io-pkt, io-sock does not support using IPv4 shorthand for addresses (e.g., 127.1) in its /etc/hosts. Use four-part internet addresses only (e.g., 123.123.12.1). For more information, see the FreeBSD hosts documentation (https://www.freebsd.org/cgi/man.cgi?query=hosts&sektion=5&manpath=FreeBSD+13.0-RELEASE+and+Ports).
The io-sock packages include a compatible version of etc/protocols. Unlike io-pkt, running io-sock without etc/protocols generates errors. For information on adding io-sock versions of files when you build your BSP, see “Modifying a BSP to support io-sock.”
When RAW packets are sent with the IP header, io-sock converts ip_len and ip_off from host byte order to network byte order. Because io-pkt does not perform this conversion, you may need to revise your application code.
The UNIX-domain protocol family that io-sock uses is ported from FreeBSD. Differences from the UNIX-domain protocol family used by io-pkt include different behavior for the LOCAL_CREDS socket option and the SCM_CREDS control message. For more information, see the FreeBSD unix documentation (https://www.freebsd.org/cgi/man.cgi?query=unix&sektion=4&manpath=FreeBSD+13.0-RELEASE+and+Ports).
The accept() function returns EINTR if the socket is closed locally. (The io-pkt version of accept() returns ECONNABORTED). For more information, see the FreeBSD accept() documentation (https://www.freebsd.org/cgi/man.cgi?query=accept&sektion=2&manpath=FreeBSD+13.0-RELEASE+and+Ports).
If you use connect() to connect to a socket after you have shut down its connection using shutdown(), connect() returns the error EINTR. (The io-pkt version of connect() returns EISCONN.) For more information, see the FreeBSD connect() documentation (https://www.freebsd.org/cgi/man.cgi?query=connect&manpath=FreeBSD+13.0-RELEASE+and+Ports).
The abilities io-sock uses to govern specific networking operations are different than the io-pkt ones. There are also differences in the sysctl commands used to drop the privileges io-sock needs during startup and apply a reduced set of privileges normal operation. For more information, see “Privilege control.”
With Plug and Play, an interface is automatically attached after it is inserted into the bus, provided there is a driver loaded that supports the interface.
For io-sock, Plug and Play is enabled by default. However, you may need to disable Plug and Play if you want to run multiple instances of the stack with two or more Network Interface Controllers of the same type. For more information, see “Running multiple stacks with network interface controllers of the same type.”
FreeBSD has deprecated some of the io-sock equivalents of functions that io-pkt provides. For a list of these APIs and the ones that replace them, see “Socket API.”