Developer Resources: Board support packages; Foundry27 projects; Forums

QNX Technical Articles

QNX® Momentics® 6.3.0 PE and SE Maintenance Patch for the QNX Momentics Extended Networking TDK 1.0.1 TCP/IP Stack (Patch ID 236) Release Notes

QNX® Momentics® Development Suite 6.3.0 SP2 PE and SE

Date of this edition: June 07, 2006

Target OS: QNX^® Neutrino^® 6.3.0 SP2, with the Extended Networking TDK 1.0.1

Host OS: Microsoft Windows XP SP1 and SP2, 2000 SP4, or NT SP6a; Sun Solaris 7, 8, 9, or 10; QNX^® Neutrino^® 6.3.0 SP2; Linux Red Hat 8, 9, or Enterprise WS 3 or 4

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.

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

Some of these fixes correct problems that can affect your system's TCP/IP service availability, so we recommend that you update to the binary versions included in this patch; see reference numbers 21549, 21962, 25036, and 38470.

This patch requires the utilities route, arp, netstat, and sysctl from the Maintenance Patch for the QNX Momentics 6.3.0 SP2 Network Protocol Components (Patch ID 234).

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 hadn't 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)
When timeouts are applied in the TCP/IP stack, a certain amount of rounding can occur, which can affect when a timeout occurs. The timing resolution of the stack can also affect this. We've added a new option, nd6_timeo, to make the timing more precise for IPv6 if you need this. This option (e.g. io-net -ptcpip-v6 nd6_timeo) directs the TCP/IP stack to check for timeouts every half second instead of every second. (Ref# 38655)
The lifetime of default routers is now stored and reported correctly. You can display this information with the ndp -r command. (Ref# 38616)
When multiple threads at the same priority sent data on a stream socket, the data would sometimes be intermixed in a nonintuitive way when received at the peer. We've fixed this. (Ref# 24873)
The TCP/IP stack no longer causes io-net to run READY when using the SO_BINDTODEVICE socket option. This could have occurred if a socket were bound to one network interface, but a packet arrived on another network interface that had no socket bound to it, targeting the same IP port. Applications that could have been affected by this behavior include dhcp.client, dhcpd, dhcprelay, and bootpd. (Ref# 25036)
When unlinking Unix Domain Name pathnames, and binding new pathnames, the stack formerly might have maintained a reference to freed memory, which could have caused the bind() function to fail for Unix sockets, or corrupted the TCP/IP stack's memory. We've corrected this. (Ref# 38470)
When the number of interfaces is greater than 8, the stack formerly could incorrectly assign two interfaces with the same interface index. This has been fixed. (Ref# 25359)
We've changed the source to be compatible with GCC 3.4.4 (Ref# 26682)
The TCP/IP stack no longer faults when you use the ioctl() SIOCGIFALIAS to get information on an address that doesn't exist. (Ref# 25166)
The TCP/IP stack formerly could sometimes generate a double reply in response to sin fd queries. This didn't cause any issues, but made kernel traces confusing. (Ref# 25856)
The stack formerly could corrupt an internal packet cache and then fault when more than three link layer types were in use (e.g. ethernet, PPP, other). (Ref# 28896)

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 weren't being displayed properly when the route show command was used. This has been fixed. (Ref# 23037)

sysctl, npm-tcpip-v4.so, <netinet/icmp_var.h>

The TCP/IP stack would always respond to the ICMP timestamp request. You can now turn this feature off with the sysctl utility or the sysctl() function. The object to control this is net.inet.icmp.tstamprepl; the default is 1 (on). (Ref# 23329)

sysctl, npm-tcpip-v4.so, <netinet/in.h>, <netinet/ip_var.h>

The TCP/IP stack by default uses sequential IP header IDs. You can now enable random IP header IDs, by using the sysctl utility or the sysctl() function. The object to control this is net.inet.ip.random_id; the default is 0 (off). (Ref# 23328)

Known issues