ptx/TCP/IP V4.6.3
Release Notes


Introduction

These release notes support V4.6.3 of the ptx®/TCP/IP software intended for use with NUMA and Symmetry® systems. Read this document before you install and run this release of the ptx/TCP/IP software.


Product Compatibility

The following software products are prerequisites for ptx/TCP/IP V4.6.3:


Features in ptx/TCP/IP V4.6.x

The following features are part of the TCP/IP V4.6.x releases.


New Version of BIND

The version of BIND that is included in this release of ptx/TCP/IP is V4.9.8. The updated version of BIND addresses vulnerabilities announced in CERT Advisory CA-2001-02, "Multiple Vulnerabilities in BIND."


POSIX Threads

To enable porting of various third party applications to DYNIX/ptx, ptx/TCP 4.6 libraries (with some exceptions) have been modified to conform to the POSIXTM threads standard.


ATTENTION

The ABI sockets library (libsocket.so.1) is NOT thread-safe.

Binaries compiled on ptx/TCP V4.1.x or later should not specify -linet to link with libinet.so. libinet.so does not contain any useful function in these releases. libinet.so is provided so that binaries built on ptx/TCP V4.0.x and earlier may run on later versions.


The following libraries/modules are thread-safe:

Note that the following libraries are not part of ptx/TCP, but are thread-safe:

The following libraries/modules are not thread-safe:

The following APIs are thread-safe and have no changes to their interfaces:

The following functions have been made thread safe without any change in their use except that they might fail with h_errno set to ENOMEM. This can happen when the system is low on memory and the implementation is not able to allocate thread-specific data.

The following APIs cannot be made thread-safe without changing the interfaces. Therefore, the existing functions are left unchanged, but a new set of functions is provided.

Function

Thread-safe Alternative

inet_ntoa()

inet_ntoa_r() -- additional argument: 16 byte character buffer

link_ntoa()

link_ntoa_r() -- additional argument: 64 byte character buffer


Interfaces with no change:

The following APIs are left unsafe. These calls should be made on a per-process basis. Typically, multiple threads in the same process do not make these calls simultaneously. If they need to do so, an appropriate synchronization mechanism needs to be followed.

struct __res_state _res

The resolver routines use this global structure to maintain the global configuration and state information of the resolver.

This data object is left UNSAFE and cannot be used in multiple threads simultaneously. However, the calls to resolver by getXXXbyYYY() routines are thread-safe, because they have been serialized, using a mutex lock.


Multidrop Output

The NUMA quad-based architecture imposes a high cost on cross-quad traffic. To achieve higher speeds, listener processes in a system can be run on the same quad as the interface on which the data is expected for the listener. This is achieved by assigning different addresses (on the same subnet) to interfaces, and binding the listening endpoints to those addresses. Because of this setup, the data received by the server follows the most efficient path to the listening application.

To achieve quad-specific output, multiple interfaces can be linked in a multidrop set and output to any of the interfaces will be delivered through a quad-local member of the set, if there is one. This avoids costly cross-quad transfer of output data and can result in better throughput.

Improvement might also be the result of greater than media speed throughput on the same IP subnet if it is a switched network. For example, traditional ethernet setups can support only 100 Mbps on the wire. In a switched setup, multiple hosts can communicate at 100 Mbps while on the same IP subnet. With multidrop this becomes an additional advantage since the output will go out different interfaces rather than being directed out the one interface to which the route points.

This is not a general solution. To achieve the best results, you must customize the system for optimum performance.


ATTENTION

The multidrop parent interface is for reference only. ifconfig commands will not work with it.



ifadmin

Use the ifadmin utility to create multidrop interfaces and child interfaces linked to a parent. Support of multidrop includes the following ifadmin options:

/etc/ifadmin multidrop <name>
/etc/ifadmin link <parent name> <child name>
/etc/ifadmin unlink <parent name> <child name>

Here is an example:

# /etc/ifadmin multidrop md0
# /etc/ifadmin link md0 pe0
# /etc/ifadmin link md0 pe4
# /etc/ifadmin link md0 pe8

Use the multidrop option to ifadmin to create a multidrop interface. After creating an interface, administrators can add one or more (non-multidrop) interfaces as children of the multidrop interface. Output to any of the child interfaces is sent to the nearest (in terms of quad location) child interface for output. The ifadmin unlink option removes an interface from consideration for output that is done through the multidrop interface.


ATTENTION

The interfaces forming a multidrop must conform as follows:



resh

The FreeBSD resh Version 8.3 has been ported to ptx/TCP V4.6.0. This replaces the earlier TLI-based implementation distributed with ptx/TCP.

New command arguments are as follows:

-d
Turns on socket debugging (using setsockopt(2)) on the TCP sockets used for communication with the remote host.
-t timeout
Allows a timeout to be specified (in seconds). If no data is sent or received in this time, resh will exit.

ftp

The ftp distributed from ptx/TCP V4.6.0 onwards will be a BSD sockets-based implementation as compared to the TLI-based version distributed in the previous ptx/TCP releases. This is a port of FreeBSD ftp Version 8.4.

Note the following changes in the commands supported by ftp.

New Command Line Option

-p
Enables passive mode operation for use behind connection filtering firewalls

Also if the ftp binary is renamed as pftp or if the environment variable FTP_PASSIVE_MODE is defined, ftp operates in the passive mode.

New ftp Commands

Changes in the .netrc File

The .netrc file contains login and initialization information used by the autologin process. It resides in your home directory. The .netrc file will recognize the token default.

This is the same as the machine name except that the default matches any name. There can be only one default token and it must be after all machine tokens. This is normally used as follows:

default login anonymous password user@site

This gives you an automatic anonymous ftp login to machines not specified in .netrc. This can be overriden by using the -n flag to disable autologin.

Commands Dropped in This Release

slow
This ftp does not have the slow option (both command line and ftp command) to slow down the data transfers.
autologin
See immediately preceding section entitled "Changes in the .netrc File."
connect
Instead has ftp as a command.
remotehelp
Has been renamed rhelp.

ftpd

The FreeBSD ftpd Version 8.4 has been ported to ptx/TCP/IP V4.6.0. This replaces the earlier TLI-based implementation distributed with ptx/TCP/IP.


New Command Line Options

-D Option

The -D option allows ftpd to detach and become a daemon, accepting connections on the FTP port and forking children processes to handle them. This involves less overhead than starting ftpd from inetd and is, therefore, useful on busy servers to reduce load.

-R Option

The -R option allows ftpd to revert to historical behavior with regard to security checks on user operations and restrictions on PORT requests. Currently, ftpd will only honor PORT commands directly to unprivileged ports on the remote user's host (which violates the FTP protocol specification but closed some security holes).

-S Option

The -S option allows ftpd to log all anonymous transfers to the file /var/log/ftpd when this file exists. The anonymous transfer logs will not be written to EES since these are neither events nor error conditions of ftpd. This is a security measure of logging all anonymous ftp transfers.

-T maxtimeout Option

This option specifies the maximum timeout period that a client can request. The maximum period allowed can be set to maxtimeout seconds with the -T option. The default is two hours.

-a address Option

This option has an effect only when the -D option is specified. After specifying both options, ftpd will accept connections only on the specified address.

-p file Option

This option has an effect only when the -D option is specified. After specifying both options, ftpd will write the daemon's process ID to a file.

-A Option

This option allows anonymous ftp access.


New Requests

MDTM
Shows time that a file was last modified
REST
Restarts an incomplete transfer
SITE
Indicates non-standard commands
SIZE
Indicates the return size of a specified file
STAT
Returns the status of the server
SYST
Shows the operating system type of the remote system

The following non-standard or UNIX specific commands are supported by the SITE request:

UMASK
Changes the umask (sample usage: SITE UMASK 002)
IDLE
Sets the idle-timer (sample usage: SITE IDLE 60)
CHMOD
Changes mode of a file (sample usage: SITE CHMOD 774 filename)

MDTM and SIZE are not specified in RFC 959, but will appear in the next updated FTP RFC.


Disable ftp Access

You can use the /etc/nologin file to disable ftp access. If this file exists, ftp displays it and exits. If the /etc/ftpwelcome file exists, ftp prints it before issuing the ready message. If the /etc/ftpmotd file exists, ftp prints it after a successful login.


STAT Command Condition

If a STAT command is received during a data transfer, preceded by a Telnet IP and sync, transfer status will be returned.


Additional Authentication of Users

ftpd does an additional authentication of users as follows:


Virtual Hosts

If the system has multiple IP addresses, ftpd supports the idea of virtual hosts, which allows you to define multiple anonymous ftp areas, each one allocated to a different internet address. The /etc/ftphosts file contains information pertaining to each of the virtual hosts. Each host is defined on its own line, which contains a number of fields separated by white space:

hostname
Contains the host name or IP address of the virtual host.
user
Contains a user record in the system password file. As with normal anonymous ftp, the user's access UID, GID, and group memberships determine file access to the anonymous ftp area. The anonymous ftp area (to which any user is chrooted on login) is determined by the home directory defined for the account. User ID and group ID for any ftp account may be the same as for the standard ftp user.
statfile
Indicates the file to which all file transfers are logged; the default is /var/log/ftpd.
welcome
Displays the welcome message before the server ready prompt. The default is /etc/ftpwelcome.
motd
Indicates the file displayed after the user logs in. The default is /etc/ftpmotd.

Defining a virtual host for the primary IP address or host name changes the default for ftp logins to that address. You can leave the user, statfile, welcome, and motd fields blank, or use a single hyphen (-) to indicate that the default value should be used.


New Files

The following new files affect the behavior of ftpd:

/etc/ftpusers
Lists unwelcome/restricted users and groups.
/etc/ftpchroot
Lists normal users who should be chrooted.
/etc/ftpwelcome
Contains welcome notice.
/etc/ftpmotd
Contains welcome notice after login.
/etc/nologin
Displayed and access refused.
/var/log/ftpd
Contains log file for anonymous transfers.

-m Option No Longer Supported

This ftpd does not have the command line option -m, which the previous version used to log anonymous ftp sessions.


Service Type in inetd.conf

Since this ftpd is a sockets-based implementation, the entry in inetd.conf should be as follows:

ftp 		stream	tcp 	nowait root /usr/etc/ftpd ftpd

This will be ensured at installation time.


ifconfig

The ifconfig command distributed with previous versions of ptx/TCP/IP was not consistent in reporting errors. This made the writing of scripts difficult. The ifconfig in ptx/TCP/IP V4.6.0 reports the following error codes:

0
Success
1
Could not create socket
2
ioctl SIOCGIFFLAGS to get the interface flags failed
3
ioctl SIOCGIFMETRIC to get the interface metric failed
4
ioctl SIOCGIFMTU to get the interface MTU failed
5
A keyword in the command line requires an argument
6
ioctl SIOCSIFMETRIC failed to set the interface metric
7
ioctl SIOCSIFMTU failed to set the interface MTU
8
Cannot assign a broadcast address to non-broadcast interface
9
Cannot assign destination address to non-point-to-point link
10
ioctl SIOCSIFFLAGS failed to set interface flags
11
No netmask specified for the address to be set
13
Error in address format
14
No address to delete
15
ioctl SIOCDIFADDR failed to delete the address
16
ioctl SIOCDIFADDR_LINK failed to delete the address
17
ioctl SIOCAIFADDR failed to add the address
18
ioctl SIOCAIFADDR_LINK failed to add the address
19
Unknown address family address was attempted
20
Netmask for non AF_INET family specified
21
ioctl SIOCSIFNETMASK failed to set the netmask
22
ioctl SIOCSIFBRDADDR failed to set the broadcast address
23
No address specified when alias keyword used

ATTENTION

ifconfig will attempt to set the interface flags only if the new flags being specified are different from the flags already set on the interface.



Interface MTU

ptx/TCP/IP V4.4 and V4.5 implementations required you to add the LLC header size to the MTU being assigned to an interface. This has been modified to be consistent with industry standards. The interface MTU now corresponds to the data portion only and does not include the LLC header.

For example, the ethernet MTU is now 1500 (not 1502). If you use SNAP, it is 1492.


telnet

telnet has been modified to negotiate options only when establishing a connection to port 23. (The default telnet port is 23.) If the remote port is prefixed with a dash or minus sign (-), then telnet options will be negotiated.

The default mode on startup is character-at-a-time. The default modes may be overridden by specifying the desired mode in .telnetrc or by specifying the mode after escaping to the telnet prompt.


MAX UDP Datagrams (TLI and ABI Sockets)

The maximum UDP datagram that may be sent is limited by STRMSGSZ or (65535 - size of UDP and IP headers), whichever is smaller. The size of UDP and IP header without options is 28 bytes. Thus, the maximum UDP datagram is 65507 bytes. The presence of IP options increases the IP header size. This will further reduce the corresponding maximum datagram size. Previously, ptx/TCP/IP had a limit of 16K on UDP message size. The STRMSGSZ limit can be configured by setting the kernel parameter STRMSGSZ. The lower bound specified for STRMSGSZ is 16K.


ATTENTION

BSD sockets are not affected by STRMSGSZ value. The maximum datagram size when using the BSD sockets API has always been 65535 - (size of (UDP + IP headers)).



Global Loop for tcpdump

In versions of ptx/TCP/IP V4.5.x, the packets sent to the local interface (which are looped back) were not seen by tcpdump. To enable tcpdump to see these packets, the virtual interface gloop was added. To see these packets, do the following:

tcpdump -i gloop

The global loop (gloop) interface is not really an interface. tcpdump will issue the following warning:

tcpdump: WARNING: SIOCGIFADDR: gloop: Invalid argument

Ignore this warning. tcpdump will now show all packets sent to any of the local interfaces. Further filtering based on the exact IP address is possible.


rarpd over LANE

rarpd over LANE is not supported.


IP Reassembly Configuration Parameters

IP reassembly buffers are no longer allocated statically. The MAX_REASSQ configuration parameter has been dropped. Instead, two new parameters are used:

MAX_IPQ_NODES
Maximum IP reassembly queue nodes
MAX_IPQ_HDRS
Number of IP reassembly queue hash headers

Dynamic Allocation of Kernel Data Structures

In previous versions of ptx/TCP/IP, the inpcb and tcpcb structures were statically allocated at boot time according to a pre-configured limit. This had several drawbacks:

Protocol control blocks (PCBs) used by ptx/TCP/IP V4.6 are now allocated dynamically as needed, rather than statically at kernel build time (as was the case in the past). This affects the method used to configure the number of PCBs as follows:

  1. The parameters N_TCP_PCB_FREE, N_UDP_PCB_FREE, and N_RAW_PCB_FREE no longer exist. The parameter MAX_IP_PROTO undergoes a name change (it becomes N_DEV_IP, described below).

  2. The following new parameters appear:

    NSOCKET - This is the number of sockets you may allocate system-wide. Note that almost everything in TCP is now a socket; in particular, BSD sockets, ABI sockets and TLI opens of /dev/tcp or /dev/udp are all actually sockets. Opens of /dev/ip and COFF binaries using UNIX domain sockets are not really sockets underneath. For initial kernel configuration, the value of NSOCKET may be set to the sum of the old N_TCP_PCB_FREE, N_UDP_PCB_FREE, and N_RAW_PCB_FREE parameters. Note that, since memory is not allocated until sockets are used, there is no up-front memory penalty for padding NSOCKET with extremely high values.

    The socket limit (which is initalized by NSOCKET) may be changed while the system is running via kmstune of the tcp.socket pool.

    N_DEV_TCP, N_DEV_UDP, N_DEV_IP - These are the number of STREAMS opens of /dev/tcp, /dev/udp and /dev/ip allowed. These limit the number of ABI sockets and TLI endpoints, each of which consumes one stream for either /dev/tcp or /dev/udp. These parameters are not dynamically configurable (these are the number of devsw_allocs done at boot time for the respective devices). Within TCP, rlogin and telnet are both TLI-based, and consume /dev/tcp streams.

    Note that these parameters are not tunable at runtime.

    N_DEV_IP is MAX_IP_PROTO, with the name changed to make the nomenclature consistent.

    The kmstune adjustable structure pools used are named tcp.socket, tcp.socket_peer and tcp.vnode. The socket_peer and vnode pools are implicitly limited by the socket pool; so there is no need to explicitly limit them.


ATTENTION

If you install ptx/TCP/IP V4.6.x on a system that has earlier versions of ptx/TCP/IP, you will find that the following TCP/IP kernel parameters will be deleted from the site files:



Software Installation

To install this release of ptx/TCP/IP, refer to the DYNIX/ptx and Layered Products Software Installation Release Notes.


ATTENTION

If you are installing this release of ptx/TCP/IP over a previous version of ptx/TCP/IP, you need to perform the following steps to ensure a successful installation. If you are performing a scratch install, you can ignore the rest of this caution.

During the installation, you may need to modify the preview log for ptx/TCP/IP. Note that the files /etc/inetd.conf, /var/tcp/ifaddrs, /var/tcp/routetab, /etc/mail/sendmail.cf, and /etc/mail/aliases are always retained from the previous installation, regardless of their CONFLICT entries in the preview log.



ATTENTION

The reshd, ftpd, and rexecd distributed with this release are BSD-sockets based and not TLI implementations. reshd was a TLI implementation until ptx/TCP/IP V4.4.1. In this release of ptx/TCP/IP, rexecd will be disabled by default. Upon the installation of this release of ptx/TCP/IP, inetd.conf entries, such as

ftp     tli     tcp     nowait  root    /usr/etc/ftpd   ftpd
shell tli tcp nowait root /usr/etc/reshd reshd
exec tli tcp nowait root /usr/etc/rexecd rexecd

will be modified to the following:

ftp     stream  tcp     nowait  root    /usr/etc/ftpd   ftpd
shell stream tcp nowait root /usr/etc/reshd reshd
#exec stream tcp nowait root /usr/etc/rexecd rexecd

Also note that this change in inetd.conf will occur irrespective of choosing CONFLICT-SKIP or CONFLICT-replace. The inetd.conf being replaced will be saved in /usr/options/tcp/inetd_conf/inetd.conf.



Product Documentation

The following documentation is available on the online documentation CD and at http://webdocs.numaq.ibm.com/:

ptx/TCP/IP Overview
ptx/TCP/IP Administration Guide
ptx/TCP/IP Programming Manual
ptx/TCP/IP Sockets Manual
ptx/TCP/IP Kernel Error Messages

Problem Reports

This section lists the following problem-report summaries:

The number that appears in parentheses in the title of each problem report is the problem-tracking-system number assigned to the report.


Fixed Problems in ptx/TCP/IP V4.6.3

ptx/TCP/IP V4.6.3 includes fixes for the following software defects:


Fixed Problems in ptx/TCP/IP V4.6.2

ptx/TCP/IP V4.6.2 includes fixes for the following software defects:


Open Problems in ptx/TCP/IP V4.6.3

This section lists open problems in this release of ptx/TCP/IP.


ntpdate Information for Symmetry Systems


ATTENTION

Time synchronization on Symmetry systems can be affected by the bootflags command.


You can start the time daemon /usr/etc/xntpd at boot-time by uncommenting the appropriate lines in /etc/rc2.d/S50netservers. This is advisable only if you invoke /usr/etc/ntpdate -b before the xntpd starts, otherwise the time delta between the host clock and the reference clock might be too large for the xntpd daemon.

On Symmetry systems the system time will be adversely affected by the execution of a bootflags command with options that display the firmware boot parameters: -bh, -bs, -bo, and -bv. Using bootflags with these options has the side-effect of suspending the system clock for several tens of milliseconds. This error will quickly be corrected by the normal operation of xntpd. You should not execute multiple bootflags -bx commands in succession. Doing so will slow the clock faster than xntpd can handle as it attempts to correct the time. The bootflags -bx commands should be used infrequently to avoid introducing a large cumulative error in the system time.

On clustered systems the bootflags problem can cause this warning message to be printed during boot:

WARNING: Time in the cluster is NOT synchronized to within 100 msecs! 

During boot the /etc/rc2.d/S99scandump script executes a bootflags -bh command. Shortly after that the /etc/rc2.d/S99cta_in script executes /usr/bin/clust_check_time, which compares the system time to the time on the other clustered nodes. Because xntpd has not had much time to adjust the clock after the bootflags command, the delta may exceed 100ms. If you see this message you can check the system time again a few minutes after boot to verify that xntpd has synchronized the time with the other clustered nodes.

This problem does not occur on NUMA systems.


228904 - On NUMA Systems Initial Sequence Number May Not Be Unique

Multiple SYNs may not be unique if connection requests arrive while the system clock has not changed (the system clock has a 10-millisecond resolution).


238069 - Sendmail 8.8 Can Have Problems Qualifying Host Names

Sendmail expects the local host name to be a fully qualified domain name. To check that it has a fully qualified host name, it expects to see at least one dot in the name. If it does not find a dot in the name, it will assume that there was an error in the name lookups, and will pause for a period of time waiting for the name server to settle out. This causes an unnecessary delay for /etc/host based systems that do not fully qualify their host names.

Workaround: Add an alias to the host that contains a dot at the end of the name, as in the following example:

10.1.2.3    myhost  myhost.

241358 - Lack of Support for IP_GET_IF_CONFIG ioctl Breaks COFF RPC

Lack of support for the old IP_GET_IF_CONFIG ioctl breaks COFF compatibility for the RPC library. Old COFF binaries which use IP_GET_IF_CONFIG ioctl will no longer work.


244679 - routed Needs to Handle IP Aliases Better

routed can flip flop the routes between aliases if they exist on the same subnet.

Workaround: Avoid aliases on the same subnet, if possible.


246779 - FUNC: ifconfig -a Command Very Slow on Cluster

The ifconfig -a command lists the pathname of the device. If the device clone information is not found in the /etc/devinfo file or there is no devinfo file for the device, then /dev is searched for the actual device entry. This slows the command down.