QNX Technical Articles

Date of this edition: October 03, 2005

Target OS: QNX^® Neutrino^® 6.3.0 SP1 or later

Host OS: Microsoft Windows XP SP1 or 2000 SP4; 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

You must install the Maintenance Patch for the QNX Momentics 6.3.0 SP1 Full TCP/IP Stack (Patch ID 97) along with this patch. 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

• What's in this patch?
• Fixed issues
• Known issues
• Technical support

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/v6 TCP/IP stack (npm-tcpip-v6.so) for the Extended Networking TDK 1.0.1. For information about the fixes in this patch, see "Fixed issues," below.

This patch requires the utilities route, arp, and netstat from the Maintenance Patch for the Full TCP/IP Stack (Patch ID 97).

Installed files

These files are installed under $QNX_TARGET/, under the subdirectories for each supported target-platform:

• ARMBE
  • armbe/lib/dll/npm-tcpip-v6.so
• ARMLE
  • armle/lib/dll/npm-tcpip-v6.so
• MIPSBE
  • mipsbe/lib/dll/npm-tcpip-v6.so
• MIPSLE
  • mipsle/lib/dll/npm-tcpip-v6.so
• PPCBE
  • ppcbe/lib/dll/npm-tcpip-v6.so
• SHLE
  • shle/lib/dll/npm-tcpip-v6.so
• x86
  • x86/lib/dll/npm-tcpip-v6.so

Fixed issues

This patch addresses the following issues:

npm-tcpip-v6.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)
• IPv6 Neighbor solicitation packets weren't sent out correctly for duplicate address detection when the TCP/IP stack was using autoconfigured IPv6 addresses. This has been fixed. (Ref# 14526)
• The TCP/IP stack formerly could have faulted when IPv6 multicast routing was disabled. This has been fixed. Note that we don't currently provide an IPV6 multicast routing daemon, but this fix allows for future support. (Ref# 21430)
• 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)
• The TCP/IP stack (npm-tcpip-v6.so) wasn't correctly applying timeouts on network prefixes obtained from routers. This would generally result in timeouts that were too long. An early timeout could occur if a subsequent prefix advertisement were sent that was intended to extend an already established prefix. (Ref# 24300)

route, arp, netstat, npm-tcpip-v6.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)

route

Some IPv6 routes were not being displayed properly when the route show command was used. This has been fixed. (Ref# 23037)

Known issues

npm-tcpip-v6.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.