QNX Technical Articles
QNX® Momentics® Development Suite 6.3.0 PE and SE TCP/IP Stack Patch [Patch ID 97] Release Notes
Date of this edition: October 03, 2005
Target OS: QNX® Neutrino® 6.3.0 SP1 or later
Host OS: Microsoft Windows XP SP1 or SP2, 2000 SP4, or NT SP6a; Sun Solaris 7, 8, or 9; QNX® Neutrino® 6.3.0 SP1 or later; Linux Red Hat 8, 9, or Enterprise WS 3 or 4
![]() |
This patch supersedes the
Maintenance Patch for the QNX Momentics 6.3.0 SP1 Full TCP/IP Stack (Patch ID 40);
we strongly recommend that you install this patch instead of, or after,
Patch 40.
For the most up-to-date version of these notes, log into your myQNX account, and then go to the Download Center area of www.qnx.com. |
Contents
![]() |
Throughout this document, you may see reference numbers associated with particular issues, changes, etc. When corresponding with our Technical Support staff about a given issue, please quote the relevant reference number. You might also find the reference numbers useful for tracking issues as they become fixed. |
What's in this patch?
Binaries
This patch contains the full IPv4 TCP/IP stack for Momentics SE and PE (npm-tcpip-v4.so). This patch also contains the utilities netstat, route, and arp. This is a maintenance patch, which contains several fixes listed below. See Fixed Issues.
Installed files
These files are installed under $QNX_TARGET/, under the subdirectories for each supported target-platform:
- ARMBE
- armbe/lib/dll/npm-tcpip-v4.so
- armbe/usr/bin/netstat
- armbe/sbin/route
- armbe/usr/bin/arp
- ARMLE
- armle/lib/dll/npm-tcpip-v4.so
- armle/usr/bin/netstat
- armle/sbin/route
- armle/usr/bin/arp
- MIPSBE
- mipsbe/lib/dll/npm-tcpip-v4.so
- mipsbe/usr/bin/netstat
- mipsbe/sbin/route
- mipsbe/usr/bin/arp
- MIPSLE
- mipsle/lib/dll/npm-tcpip-v4.so
- mipsle/usr/bin/netstat
- mipsle/sbin/route
- mipsle/usr/bin/arp
- PPCBE
- ppcbe/lib/dll/npm-tcpip-v4.so
- ppcbe/usr/bin/netstat
- ppcbe/sbin/route
- ppcbe/usr/bin/arp
- SHLE
- shle/lib/dll/npm-tcpip-v4.so
- shle/usr/bin/netstat
- shle/sbin/route
- shle/usr/bin/arp
- x86
- x86/lib/dll/npm-tcpip-v4.so
- x86/usr/bin/netstat
- x86/usr/sbin/route
- x86/usr/bin/arp
Fixed issues
This patch addresses the following issues:
- npm-tcpip-v4.so
- The TCP/IP stack could formerly fault if you tried to get file-descriptor information (e.g. by executing sin fd) on a system where a process had called shutdown() for a TCP/IP socket descriptor, but the socket had not yet been closed. This has been fixed. You also now get more diagnostic information when you use sin fd to view information on socket file descriptors. (Ref# 21549)
- The TCP/IP stack obtains a timer, which starts at time 0, from the
process manager.
If the TCP/IP stack and a TCP/IP application that tries to connect to
a remote host start executing too soon, the TCP/IP stack may apply a
time of 0 seconds to ARP cache entry structures.
If this occurs, you may end up with a permanent ARP entry (i.e. one that never times out). You can also end up with permanent, incomplete ARP entries that never time out and that the TCP/IP stack doesn't attempt to resolve. If this happens, your host won't be able to communicate with one or (possibly) more remote hosts (i.e. the ones the TCP/IP application in the OS image is trying to reach).
You can check for permanent ARP entries by running the arp -an command and examining the output. The only permanent entries listed should be for the IP addresses assigned to your host's interfaces; there shouldn't be any permanent, incomplete entries. If you find a permanent entry that isn't for the IP address of an interface on your host, and you didn't explicitly create a permanent entry, then you could be encountering this problem. A workaround for your OS image was to delay the start of the TCP/IP stack or the first TCP/IP application by at least one second, by using the sleep command (e.g. sleep 1) or some other delay mechanism. This has been fixed, so this workaround is no longer necessary. (Ref# 21395)
- If you connect() on an unlinked or nonexistent AF_LOCAL socket, errno used to be incorrectly set to ECONNREFUSED instead of ENOENT. This has been fixed. (Ref# 21664)
- If a program called bind() for an AF_LOCAL socket, and the path namespace entry was created, the TCP/IP stack used to leak a small amount of memory, even if the path were unlinked. This has been fixed. (Ref# 21639)
- A user TCP application that was blocked on read() formerly could unblock and return 0 when the sin utility was run. It appeared as if the remote TCP application had closed its end of the socket, when it hadn't. A user symptom could be TCP server applications that terminated, closed a TCP session for no reason, or reported that the client had ended the session when it hasn't. This has been fixed. (Ref# 21962)
- The socket() function call formerly could have set errno incorrectly if the system were out of memory for AF_LOCAL sockets. (Ref# 22917)
- When the fastforward path in the TCP/IP stack was used (see the fastforward option to npm-tcpip-v4.so or npm-tcpip-v6.so), the TCP/IP stack didn't deal with the next hop gateway properly if it wasn't responding to an ARP request. The TCP/IP stack now correctly marks the route as being down and sends an ICMP-unreachable packet back to the source. (Ref# 23864)
- If a packet were to be forwarded, and there was no route specified on the gateway, the TCP/IP stack returned ICMP_UNREACH with an ICMP_UNREACH_HOST code. The TCP/IP stack has been changed to return a ICMP_UNREACH_NET code. (Ref# 23900)
- route, arp, netstat, npm-tcpip-v4.so
-
- The TCP/IP stack used a monotonic clock internally.
Interfaces that used an absolute timeout value to specify a timeout,
or to query a timeout, were converted to use a relative timeout value.
Utilities that used this interface were converted to use a relative
timeout value.
This introduced portability and maintenance issues because the
timeout values were incorrectly applied if the application wasn't modified.
These interfaces once again use an absolute timeout.
The interfaces effected are:
- The Routing Socket rt_metrics structure member rmx_expire -- the lifetime for the route
The arp, route and netstat utilities had been modified to supply a relative timeout rather than an absolute one. We've changed them back, so that they again use an absolute timeout value. (Ref# 22877)
- Inspection has shown a need to further update the arp, route, and netstat utilities to make them fully compatible with the corrections provided in the original Maintenance Patch for the QNX Momentics 6.3.0 SP1 Full TCP/IP Stack (Patch ID 40) that addressed issue 22877. (Ref# 26357)
- The TCP/IP stack used a monotonic clock internally.
Interfaces that used an absolute timeout value to specify a timeout,
or to query a timeout, were converted to use a relative timeout value.
Utilities that used this interface were converted to use a relative
timeout value.
This introduced portability and maintenance issues because the
timeout values were incorrectly applied if the application wasn't modified.
These interfaces once again use an absolute timeout.
The interfaces effected are:
Known issues
- npm-tcpip-v4.so
- If a packet is smaller than the minimum Ethernet packet size, the packet may be padded with random data, rather than zeroes. (Ref# 21460)
Technical support
If you have any questions, comments, or problems with a QNX product, please contact Technical Support. For more information, see the How to Get Help chapter of the Welcome to QNX Momentics guide or visit our website, www.qnx.com.
