ptx®/TCP/IP V4.5.4
Release Notes


Introduction

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


Product Compatibility

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


What Is New in This Release

This release of ptx/TCP/IP includes fixes for several software defects, listed in "Fixed Problems in ptx/TCP/IP V4.5.4." It also includes BIND V4.9.8, which addresses vulnerabilities announced in CERT Advisory CA-2001-02, "Multiple Vulnerabilities in BIND."


Features Added in Earlier Versions of ptx/TCP/IP V4.5


Routing Enhancements


netstat Enhancements

The output for the netstat -r command has been changed. Note the following example:

Internet:
     Destination        Gateway            Flags    Refs    Use    Netif Expire
     default            r105spl2.sequent.c UGSc       1     208      ed0
     localhost          localhost          UH         0      65      lo0
     138.95.105/24      link#1             UC         0       0 
     elm15c42           0:50:4d:0:4a:e1    UHLW       1      34      lo0
     r105spl2.sequent.c 0:0:c:0:4e:cc      UHLW       3       0      ed0    216

The output drops the ttl column and instead has an Expire column. The output also has an additional Refs column. The user cannot depend on the output being of constant width. It will vary as per the number of characters to be output per line. The number of columns however will be a constant.

Gateway can have the following values:

Regarding netstat -ra, note that only if the -a option is specified will the cloned entries be shown, as in the following output:

W     RTF_WASCLONED    Route was generated as a result of cloning


route Enhancements

New routing capabilities have been added and affect the route(1C) command. Note the following new syntax:

route -n -v -q

-n
Bypasses attempts to print host and network names symbolically when reporting actions. (The process of translating between symbolic names and numerical equivalents can be quite time consuming, and may require correct operation of the network; thus it may be expedient to forgo this, especially when attempting to repair networking operations)

ATTENTION

-n was supported by the previous version too. It is given here for completeness.


-v
(verbose) Prints additional details.
-q
Suppresses all output.

The following options have been added to the route command:

add
Adds a specific route. Note that only the format of this command has changed.
fill
Adds all routes described in a file.
flush
Removes all routes. The only family supported at this time is -inet.
delete
Deletes a specific route. Note that only the format of this command has changed.
change
Changes aspects of a route (such as its gateway).
get
Looks up and displays the route for a destination.
monitor
Continuously reports any changes to the routing information base, routing look-up misses, or suspected network partitionings.

The monitor option has the following syntax:

route [-n] monitor

The flush command has the following syntax:

route [-n] flush [family]

The only family supported is -inet.

The get and change options have the following syntax:

route [-n] command [-net | -host] destination gateway

destination
Specifies the destination host or network.
gateway
Specifies the next-hop intermediary through which packets should be routed.

Routes to a particular host may be distinguished from those to a network by interpreting the Internet address specified as the destination argument. The optional modifiers -net and -host force the destination to be interpreted as a network or a host, respectively. Otherwise, if the destination has a ``host portion'' of all zeroes, or if the destination is the symbolic name of a network, then the route is assumed to be to a network; otherwise, it is presumed to be a route to a host.

For example, 128.32 is interpreted as -host 128.0.0.32; 128.32.130 is interpreted as -host 128.32.0.130; -net 128.32 is interpreted as 128.32.0.0; and -net 128.32.130 is interpreted as 128.32.130.0.

If the destination is directly reachable through an interface requiring no intermediary system to act as a gateway, the -interface modifier should be specified; the gateway given is the address of this host on the common network, indicating the interface to be used for transmission.

The optional modifier -link specifies that all subsequent addresses are specified as link level addresses, and the names must be numeric specifications rather than symbolic names.

The optional -netmask qualifier is intended to manually add subnet routes with netmasks different from that of the implied network interface. One specifies an additional ensuing address parameter (to be interpreted as a network mask). The implicit network mask generated in the AF_INET case can be overridden by making sure this option follows the destination parameter.

Routes have associated flags that influence operation of the protocols when sending to destinations matched by the routes. These flags may be set (or sometimes cleared) by indicating the following corresponding modifiers:

-cloning RTF_CLONING
Generates a new route on use
-xresolve RTF_XRESOLVE
Emits message on use (for external lookup)
-iface ~RTF_GATEWAY
Destination is directly reachable
-static RTF_STATIC
Manually added route
-nostatic ~RTF_STATIC
Pretend route added by kernel or daemon
-reject RTF_REJECT
Emits an ICMP unreachable when matched
-blackhole RTF_BLACKHOLE
Silently discard packets (during updates)
-proto1 RTF_PROTO1
Sets protocol specific routing flag #1
-proto2 RTF_PROTO2
Sets protocol specific routing flag #2
-llinfo RTF_LLINFO
Translates a protocol address to a link address

The optional modifiers -rtt, -rttvar, -sendpipe, -recvpipe, -mtu, -hopcount, -expire, and -ssthresh provide initial values to quantities maintained in the routing entry by transport level protocols, such as TCP.

These optional modifiers may be individually locked. Precede the specified modifier with the -lock meta-modifier, or specify that all ensuing metrics be locked by the -lockrest meta-modifier.


ATTENTION

The -lock option when used to lock the MTU disables Path MTU discovery on that route.


In a change or add command in which the destination and gateway are not sufficient to specify the route, the -ifp or -ifa modifiers may be used to determine the interface or interface address.

All symbolic names specified for a destination or gateway are looked up first as a host name using gethostbyname(3). If this lookup fails, getnetbyname(3) is then used to interpret the name as that of a network.

Route uses a routing socket and the new message types RTM_ADD, RTM_DELETE, RTM_GET, and RTM_CHANGE. As such, only the superuser or a user with network-administration privileges may modify the routing tables.


ATTENTION

The -a option is no longer supported. It's functionality is now provided by the fill command.


For more information about the route command, refer to the route(1C) man page.


routed Enhancements

routed has been enhanced with the following options:

-h
Does not advertise point-to-point routes.
-m
Advertises host and point-to-point routes to primary interface.
-A
Does not ignore RIPv2 authentication if we don't care about it.
-T
Specifies a trace file for debugging output.
-P
Specifies parameters on command line as if were in the /etc/gateways file.
-F
Fakes default routes on some interfaces.

PF_ROUTE Domain

The PF_ROUTE domain has been added to the sockets interface

int socket(PF_ROUTE, SOCK_RAW,)<protocol>)

where (int) protocol may take the values AF_INET or 0.


Routing Messages

Routing messages are exchanged by issuing read() and write() system calls on a routing socket. The routing messages are: RTM_XXX, where XXX can be: ADD (*), CHANGE (*), DELADDR, DELETE (*), GET (*), IFINFO, LOCK (*), LOSING, MISS, NEWADDR, REDIRECT, or RESOLVE. The kernel may send all the these messages to the user. The user may send only the starred (*) messages to the kernel.

1. rt_msghdr structure

This structure is used by RTM_ADD, RTM_DELETE, RTM_CHANGE, RTM_GET, RTM_LOCK, RTM_LOSING, RTM_MISS, RTM_REDIRECT, and RTM_RESOLVE.

struct rt_msghdr { 
     u_short rtm_msglen; /* to skip over non-understood messages
     */ 
     u_char rtm_version; /* future binary compatibility */ 
     u_char rtm_type; /* message type */ 
     u_short rtm_index; /* index for associated ifp */ 
     int rtm_flags; /* flags, incl. kern & message, e.g. DONE */ 
     int rtm_addrs; /* bitmask identifying sockaddrs in msg */ 
     pid_t rtm_pid; /* identify sender */ 
     int rtm_seq; /* for sender to identify action */ 
     int rtm_errno; /* why failed */ 
     int rtm_use; /* from rtentry */ 
     u_long rtm_inits; /* which metrics we are initializing */ 
     struct rt_metrics rtm_rmx; /* metrics themselves */
};

2. if_msghdr structure

This structure is used by RTM_IFINFO.

struct if_msghdr { 
     u_short ifm_msglen; /* to skip over non-understood messages
     */ 
     u_char ifm_version; /* future binary compatibility */ 
     u_char ifm_type; /* message type */ 
     int ifm_addrs; /* like rtm_addrs */ 
     int ifm_flags; /* value of if_flags */ 
     u_short ifm_index; /* index for associated ifp */ 
     struct if_data ifm_data;/* statistics and other data about if */
};

3. ifa_msghdr structure

This structure is used by RTM_NEWADDR and RTM_DELADDR.

struct ifa_msghdr { 
     u_short ifam_msglen; /* to skip over non-understood messages
     */ 
     u_char ifam_version; /* future binary compatibility */ 
     u_char ifam_type; /* message type */ 
     int ifam_addrs; /* like rtm_addrs */ 
     int ifam_flags; /* value of ifa_flags */ 
     u_short ifam_index; /* index for associated ifp */ 
     int ifam_metric; /* value of ifa_metric */
}

Sysctl Interface for CTL_NET/PF_ROUTE and CTL_NET/PF_INET

This release of TCP contains a limited implementation of the sysctl interface, namely CTL_NET/PF_ROUTE and CTL_NET/PF_INET. sysctl is a kernel utility that retrieves the kernel state and allows processes with the appropriate privilege to set the kernel state. The state to be retrieved or set is described using a Management Information Base (MIB) style name, or a dotted set of components.

The -a flag lists all the currently available string or integer values. The -A flag lists all the known MIB names, including tables. MIB entries (kernel data) with string or integer values will be printed with the -a flag, and for table values, the name of the utility that will retrieve them is displayed.

The -n flag specifies that the printing of the field name should be suppressed and that only its value should be output. This flag is useful for setting shell variables.

If just a MIB style name is given, the corresponding value is retrieved. If a value is to be set, the -w flag must be specified and the MIB name followed by an equal sign and the new value to be used.

The information available from sysctl consists of integers, strings, and tables. The subset supported by this release of ptx/TCP/IP consists of:

top level: CTL_NET

second level: PF_ROUTE, PF_INET


Deprecated ioctls

The following ioctls have been deprecated:


ATTENTION

You should not use these ioctls. With the availability of routing sockets in this release, these ptx specific ioctls are no longer required. They are supported in this release to allow older programs to continue. They will be REMOVED in the next major release.



IP Multicasting

IP Multicasting allows you to direct the same packets to multiple destinations at the same time. Consequently, IP Multicasting is much more efficient than unicasting (sending a separate copy to each individual destination). The benefits of IP Multicasting are; 1) the sender only has to send out one copy of the information packet instead of many, 2) the information is delivered in a more timely, synchronized fashion because all destinations receive the same source packet, 3) multicasting can be used to send information to destinations whose individual addresses are unknown (similar to a broadcast), and 4) it reduces the overall number of packets on the network (that is, one multicast packet sent instead of many unicast packets).

The following socket options have been added:

The netstat and ifconfig utilities have been modified to display associated multicasting information.

For more information, refer to the ptx/TCP/IP Sockets Manual.

The output of the netstat -s command has been changed to reflect the multicast information. Instead of specifying the number of broadcast datagrams dropped, the reference will be to the number of broadcast/multicast packets.

The current output, such as :

xxx broadcast datagrams dropped: due to no local port

has been modified to:

xxx broadcast/multicast datagrams dropped due to no socket

A new Internet Group Multicast Protocol (IGMP) section will have output, such as:

x messages received
x messages received with too few bytes
x messages received with bad checksum
x membership queries received
x membership queries received with invalid field(s
x membership reports received
x membership reports received with invalid field(s
x membership reports received for groups to which we belong
x membership reports sent


Path MTU Discovery

Path Maximum Transmission Unit (MTU) Discovery applies to the minimum MTU on any network that is currently in the path between two hosts. If the packets exchanged between the two endpoints are smaller than this size, the throughput is reduced. Reduced throughput can occur on implementations in which the maximum packet sizes are 512/536 bytes when the connection is not on the local net. Throughput problems can also occur when packets greater than Path MTU are transmitted, because the intermediate router has to fragment and drop packets. Path MTU Discovery avoids these problems, because it determines the maximum-sized datagram that can be sent on a path without breaking it into fragments.

Path MTU Discovery will always be attempted on TCP connections. UDP connections will use the path that MTU has discovered. The MTU is discovered relative to a path (that is, route).

To turn off the Path MTU Discovery process, you should use the route command as follows:

route change <route> [-net | -host] -lock -mtu (MTU)

ATTENTION

The order of -lock and -mtu is important.


Refer to the route(1C) man page for more information.

Note that the ALLNETSARELOCAL and SUBNETSARELOCAL configuration parameters have been removed.


Network Time Protocol

Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. NTP accurately times client transmissions within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to a primary server that is synchronized to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver. For example, typical NTP configurations use multiple redundant servers and diverse network paths to achieve high accuracy and reliability. Note that the current version of the protocol (NTP Version 3) is defined in RFC 1305.

The implementation of NTP in ptx/TCP/IP is based on the 3-5.92 distribution from David Mills of the University of Delaware.


ATTENTION

The implementation of ptx/TCP/IP does not provide support for hardware reference clocks other than LOCAL_CLOCK, which enables a free running system clock. Also, this implementation does not support DES encryption algorithms, and kernel support for RFC 1589. It does, however, support MD5 encryption.


The distribution consists of the xntpd daemon, the querying and configuration utilities xntpdc and ntpq, as well as the ntpdate and ntptrace programs.

NTP and the timed utility can synchronize the system clock and distribute time. They should not be used simultaneously, unless only one is configured to adjust the local clock, and the other is configured to only distribute the time. For example, if NTP is set up to adjust the system clock, then timed should only be configured to distribute the time - not to adjust the local system clock.

Typical configurations for NTP service include setting up a hierarchy of servers that distribute time to the various subnets on a network.

To set up the NTP service, you must configure the /etc/ntp.conf file with the needed time sources and other options, and then invoke the xntpd daemon. If you will be using NTP to adjust the system clock, it is strongly recommended that you run ntpdate with the -b option before invoking the xntpd daemon. By doing so you will synchronize the date and time with the sources you specify to within a small offset. If the offset between the local clock and the synchronization sources is very large, the xntpd daemon will exit after logging a warning message (via syslog), telling you to manually correct the date, or use date(1) or ntpdate(3N). The larger the offset between the clocks when xntpd is invoked, the longer it will take to synchronize to the time sources. For this reason, it is not recommended that you uncomment the lines for the xntpd daemon in /etc/rc2.d/S50netservers, which will invoke xntpd as part of the boot process.

For more information, please refer to the ptx/TCP/IP Administration Guide, as well as to the man pages on xntpd(3N), xntpdc(3N), ntpq(3N), ntpdate(3N), and ntptrace(3C).


tcpdump

tcpdump now reads and writes in Network General Sniffer format and can dump output data in hexadecimal and ASCII.

tcpdump now has the following new options:

tcpdump -W -r

-W
Causes the tcpdump output to be stored in the specified filename in the Network General File format. The -w option will continue to work as it does now. That is, it will write to the specified file in the raw tcpdump format.
-r
Takes the input from a file stored in the Sniffer or the tcpdump format. The tcpdump program will autodetect the file format.

tcpdump can now display link level packets along with their MAC and link-level headers. For example, ARP packets are also displayed now. The previous version of tcpdump could only display IP packets.

You can run tcpdump on a specific interface by using the -i option. With no filter, the previous version of tcpdump displayed all the IP packets on all the configured interfaces irrespective of the specified interface.


TCP Window Scaling

Window scaling allows for greater than 64KB TCP windows for maximum throughput (when sb_max is greater than 64KB is how it detects it needs TCP window scaling). A user may specify a large receive buffer and correspondingly send a TCP option with a large window. An ordinary user may set the socket buffers to be up to sb_max bytes. A superuser or a user with NET_ADMIN privileges may set the buffers to be of any size. That is, the limit of sb_max bytes does not hold.

The bp facility may also be used to modify sb_max on a running kernel.

The window scale option will be sent in SYN segments and may be sent in a SYN-ACK segment if the window scale option was present in the received SYN segment.

tcpdump will print the TCP window scale option with the SYN segments in its output.


Additional Information


Many Routes

netstat -r will show a lot of routes.

Because of the addition of the cloning/prcloning (protocol cloning) features mentioned above (see "Routing Enhancements"), you will see many routes pop up and go out of existence on netstat output. This is expected and is the correct behavior.

All the cloned routes will have the W flag in netstat output. All the prcloned routes will have the 3 flag in netstat output. For local routes the netstat output will show the MAC addresses or link number. See the man page for netstat(1A).

The time of disappearance of routes varies. Local routes vanish after about 20 minutes and gateway routes after 1 hour. This information applies to cloned routes only. netstat output will show the number of seconds a route is expected to expire (if ever).

Indirect routes will not be deleted when the local outgoing interface is deleted. For example, the default route will not vanish when the interface leading to the default router is removed.

The protocol cloned routes will be visible when netstat -ra is used. To see all routes except protocol cloned routes, use netstat -r.


/var/tcp/routetab Format Change

In earlier versions of ptx/TCP/IP, you could add a default route in the /var/tcp/routetab file, as is shown in the following example:

net,default,138.95.105.119,1

If you want this default route to be in the list that is installed at startup, you can place the same line in the routetab file as follows:

add -net default 138.95.105.119

ATTENTION

The netmask for the default route is 0.0.0.0. If a faulty or illegal netmask is given, it is ignored. A netmask of 0.0.0.0 is always used for the default route.



Mandatory Netmasks

The ifconfig command has been updated to require netmasks whenever you add an interface. For more information, see the route(1C) and routed(8) manpages.


ptx/ADMIN Menu Changes

The routing enhancements have caused changes in some ptx/ADMIN menus. Refer to the ptx/TCP/IP Administration Guide for more information.


Specify No ARP for ATM V1.0.2

If you are running ptx/ATM V1.0.2 and want to add an ATM interface, use the Add Interface Menu. You can find this menu via the menu system:

MENU PATH

ptx/ADMIN Path

Network Administration -> TCP/IP Management -> TCP/IP Administration -> Basic Interface Administration -> Add Interface

In response to the question regarding the use of ARP, you should enter no, as follows:

   Use ARP?
(Say no for ITX and loopback) [n]

If you do not use the menu system, use the ifconfig command to specify no ARP for ATM interfaces (fa devices), as is shown in the following example:

ifconfig fa0 192.168.20.20 netmask 255.255.255.0 noarp

If you have an existing ATM configuration, you will need to change it to no ARP. You can do this through the menu system:

MENU PATH

ptx/ADMIN Path

ptx/ADMIN -> Network Administration -> TCP/IP Management -> TCP/IP Administration -> Basic Interface Configuration -> Change Interface

If you do not use the menu system, edit /var/tcp/ifnets.


ATTENTION

If you are running ptx/ATM V2.0.x, refer to the corresponding ptx/ATM release notes to set the ARP correctly (for CLIP or LANE).



Setting Metrics and Modifying Routes

You can use the route command to change the metrics on a route. If you specify a route (host or net) that does not exist, the change will apply to the default route or a more general net route. This is because the packet for the destined route will actually go out through the default route or the more general net route.

For example, if the route table has two entries:

default
a.b/16

and you modify the route's metrics as follows:

route change a.b.c.d -mtu 1200

The route a.b/16 will be updated.

If a.b.c.d had a host route, the MTU on that route would have been modified.


PR239511 Half-formed Routes

If you attempt to add an IP address but that address belongs to another node on the link, the following may result:

A route might appear with a MAC address of a different machine. This is because a gratuitous ARP is sent out on the network. If the IP address is in use, an ARP reply is received, and it causes a route to be added with the replying node's MAC address. This is the correct behavior. There will also be an error generated stating that the IP address is already in use. The ifconfig command will fail.


Path MTU Discovery

Setting ip_mtuinctimer1/ip_mtuinctimer2 to 0 will stop attempts at discovering route increases. However if on any connection data has been sent with a higher MTU, that MTU might get updated in the route after the user sets ip_mtuinctimer1/ip_mtuinctimer2 to 0.


TCP Window Scaling

A superuser or network administrator may create a socket and set its buffers to be greater than sb_max (default is 256 KB) bytes in size. If a setuid() to a normal user is done, there is no change in the socket buffer limits. If the socket was a listening socket, then sockets created as a result of accept() will inherit the large buffers (even though now the effective UID is that of a normal user). Any attempt to modify the socket buffer sizes (socket options SO_RCVBUF/SO_SNDBUF) at normal privilege will cause the limit of sb_max to be applied.


Loopback When Interface Is Down

If the interface is marked up (IFF_UP), packets sent to the IP address on the interface will always be locally looped back. In previous releases, IFF_RUNNING also was required to allow loopback on a local interface.


FTP CERT Advisory CA-97.27 - FTP_bounce

This ptx/TCP/IP V4.5.1 and later adhere to the CERT advisory in that the ftp utility does not accept a PORT command where the specified port is in the reserved range.


Reshd

From ptx/TCP/IP V4.4.2 onwards, the reshd on DYNIX/ptx systems is BSD sockets-based. When ptx/TCP/IP V4.4.1 or earlier versions of ptx/TCP/IP are upgraded, the /etc/inetd.conf file is updated to reflect this. However, if the system has a reshd that does not reside in /usr/etc/reshd, then such a change is not applied.


IP Forwarding

ptx/TCP/IP can act as a gateway; however, this functionality is controlled by the ipforwarding parameter. In ptx/TCP/IP V4.5.1 and later, this parameter is set to 0 by default. If ptx/TCP/IP is required to run as a gateway, you must set ipforwarding to 1.


Timestamp Options and PAWS/RTTM

Timestamps can be used on a TCP connection to achieve a more accurate round trip time measurement (RTTM) estimate.

Window scaling allows large segments to be transferred on a connection. Such segments are needed on large bandwidth-delay product connections. Timestamps on such connections are used to implement the PAWS (protection against wrapped sequence numbers) algorithm.


ATTENTION

PAWS prevents lost segments (including those already retransmitted and accepted) from reappearing within an MSL period as valid segments. PAWS considers the timestamp value as an extension of the sequence space and avoids old duplicates.


The time stamp option is controlled by the variable tcp_do_tstmp.

bp -s /unix /dev/kmem tcp_do_tstmp 1 enables the timestamp option on the connections.

If the global tcp_do_stmp option is set, setsockopt can be used to enable/disable the time stamp option for each connection.

A privileged BSD sockets user may turn on the timestamp option on connections even if the global flag tcp_do_tstmp is 0. For ABI sockets, the global tcp_do_tstmp flag must be 1 to be able to use timestamps.

The timestamps can be enabled/disabled only in the following TCP states:

BSD sockets
CLOSED or LISTEN
ABI sockets
LISTEN

The timestamp option is not available on TLI connections.

The timestamp option will be used on the connection only if the peer has enabled timestamps, too.


ATTENTION

Since the timestamp option involves transmitting an extra 12 bytes for every TCP segment that is transmitted on the connection, you should use it only when necessary.



/etc/nsswitch.conf and Sendmail

If ptx/NFS is not installed, you must create an /etc/nsswitch.conf file so that Sendmail can resolve the hostname and look up aliases. Create this file so that it contains the following entry:

hosts: files dns


ptx/RPC COFF Binaries No Longer Work

Since the IP_GET_IF_CONFIG ioctl no longer exists, any binary that relies on this ioctl will not work. For example, binaries based on ptx/RPC such as old ptx/RPC COFF binaries, will not work.


BSD Socket SIOCGIFCONF

As of ptx/TCP/IP V4.4.0, the information ioctl, SIOCGIFCONF, replaced IP_GET_IF_CONFIG. SIOCGIFCONF is a BSD-standard ioctl that returns socket address structures in two formats:

Refer to the ptx/TCP/IP Programming Guide for a thorough discussion of SIOCGIFCONF.


Making a Connect Call from LISTEN

In earlier versions of TCP, an ABI socket/TLI endpoint could make a connect()/t_connect() call on a listening endpoint even if there were unaccepted connection requests waiting to be accepted on the endpoint. A BSD sockets endpoint never allowed connect() to succeed on a listening endpoint.

From TCP V4.5.1 onwards, the connection request will succeed on a listening endpoint (ABI/TLI/BSD socket) only if there are no unaccepted connection requests. Otherwise, a connection on a listening endpoint will fail with EOPNOTSUPP.

Thus, any existing ABI socket/TLI binaries making a connect call from the LISTEN state may fail. However, it is very unlikely such binaries exist, and such code is not approved.


Modifications to TCP_GET_PCBS and UDP_GET_PCBS ioctls

Both the TCP_GET_PCBS and UDP_GET_PCBS ioctls return the tcp_pcbinfo structure. The i_state field of these structures has been renamed to i_filler in ptx/TCP V4.5.1. Note that the i_filler field is always set to 0.

Any program utilizing the i_state field to report the TLI state of the connections will not be able to do so. netstat will no longer display the TLI state of UDP packets.


Documentation Changes

The ptx/TCP/IP Administration Guide in Chapter 6, "Starting and Stopping Sendmail," provides the wrong path for sendmail in examples throughout the chapter. The correct path for the sendmail program is /usr/lib/sendmail, not /etc/mail/sendmail.


Software Installation

For instructions on how 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 ptx/TCP V4.5.4 over a previous version of TCP, 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.

After the installation is complete, ensure that you have your original version of the /etc/inetd.conf file.

You may also need to make the following change to the /etc/inetd.conf file.

The version of reshd distributed with this release requires a service type of stream. If the entry specifies the tli service type, as in the following example, you will need to change it to stream.

shell   tli	tcp     nowait  root    /usr/etc/reshd  reshd -R

The corrected entry is as follows:

shell   stream  tcp     nowait  root    /usr/etc/reshd  reshd -R

If you do not make this change, remote resh services will not function.



Product Documentation

The following documentation is available on the online documentation CD:


Problems Reports

This section lists the following problem report summaries:

The numbers in parentheses identify the problems in the problem-tracking system.


Fixed Problems in ptx/TCP/IP V4.5.4

This release of ptx/TCP/IP contains fixes for the following software defects:


Open Problems in ptx/TCP/IP V4.5.4

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


228904 - On IBM NUMA-Q 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).


234193 - Need more robust ifconfigall command

ifconfigall is used to bring up interfaces and to configure them with the information supplied by the ptx/ADMIN menu system. This information is stored in the files /var/tcp/ifnets and /var/tcp/ifaddrs. ifconfigall interprets the information in these files very literally, giving rise to potential problems. This is not a problem when bringing an interface up for the first time. However, it can be a very serious problem when some interfaces are already up and ifconfigall is run, for example, when the system comes up from single- to multi-user mode.

Consider the following example. The interface used by ptx/CLUSTERS must come up when the machine is in single-user mode. When the machine goes to multi-user mode, ifconfigall is run again. It compares information about running interfaces (learned from netstat -D) with what is in its configuration files. It does literal string matching to determine if anything is different. If someone has edited the files and put in text that differs in any way from what the menu system deposits - even if it is semantically correct - ifconfigall will tear the interface down and bring it back up. This can cause serious problems in a clustered environment. A common example involves supplying the default netmask. netstat -D will not print a netmask unless it varies from the default. ifconfigall will notice that in one case a netmask is provided and in the other it is not, and it will bounce that interface.

In some situations, this bouncing can cause clustered systems to get out of sync, and one of the nodes may panic.

Workaround: Do not manually edit /var/tcp/ifnets and /var/tcp/ifaddrs. If you feel you have to do this, run ifconfigall -s before and after. After this option is supplied, ifconfigall will only report on what action it would have taken. You can verify if your changes will have the desired effect.


238069 - Sendmail 8.8 Can Have Problems Qualifying Host Names

Sendmail expects the local hostname 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.

238994 - ftpd Incorrectly Handles ABOR

ftpd in this release is TLI-based. As such, there is a conflict between the use of urgent data in the ABOR command, and the tirdwr module pushed onto the stream.

Workaround: Avoid the ABOR command in this release.


239216 - rcp Does Not Exit with PROPER EXIT STATUS

rcp uses the resh command internally while handling third party copies (where neither source nor target files are on the current machine). The problem with resh is that its exit value does not depend on the exit status of the command executed on the remote machine. (In this case, resh is invoked with rcp being the command to be executed on the source machine). As a result, we cannot determine the correct exit status.


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.


242870 - The MTU Should Not Include the Type and LLC/SNAP Portion of Frame

The MTU size includes the size of the LLC/SNAP portion of the frame. This differs from some previous releases (pre-ptx/TCP/IP V4.4.0) and other OS implementations.

Workaround: When calculating the MTU, add 2 for Ethernet II interfaces, and 8 for interfaces with SNAP headers.


243044 - Change IF Address and Flags via Menu Operations Reports Error, but Works

If you change an interface address or flags by using the TCP/IP Operations Menu, the Change Interface Address or Flags selection will report the following error even when it completes successfully:

change of interface address or flags failed

However, it will successfully make the change.


243141 - SIOCIFBRADDR ioctl Broken

An attempt to set the broadcast address for an interface using ifconfig will not work by itself. However, using ifconfig with the interface address in the command and supplying all the information will work, because it is implemented via a different ioctl. Therefore,

ifconfig pe0 192.168.1.1 netmask 255.255.255.0 broadcast 255.255.255.40

will correctly set the broadcast address to 255.255.255.40, but

ifconfig pe0 broadcast 255.255.255.40 

will not.

Workaround: Use the former method to set the broadcast address.


243257 - ftp mdir Command Broken for Local Files Other Than stdout

The ftp command "mdir" will cause ftpd to close the connection when a local file is used as the target for the mdir output.

Workaround: Pipe the output of the mdir command instead, as in the following example:

mdir foo.* "| cat > bar"

243706 - netstat -i Needs Unsigned printf Conversion for Packet Traffic

netstat variable for packet traffic needs to be unsigned. Currently netstat output can be erroneous when packet counts become large.


255653 - Misleading Error Message Displayed When IP Address Added

When an additional IP address (alias) is added to an interface, the following error message is displayed: ioctl: File exists.

Workaround: None. This message can be ignored.