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.
The following software products are prerequisites for ptx/TCP/IP V4.5.4:
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."
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:
The address of the gateway
Entries of the form link#. These entries are for a local interface. Such an entry has neither the H nor the G flags set. See the list below.
The MAC entry for the host indicated in the destination column. This entry is created by ARP and is temporary. The flags indicate:
1 RTF_PROTO1 Protocol specific routing flag #1 2 RTF_PROTO2 Protocol specific routing flag #2 3 RTF_PROTO3 Protocol specific routing flag #3 B RTF_BLACKHOLE Just discard pkts (during updates) C RTF_CLONING Generate new routes on use c RTF_PRCLONING Protocol-specified generate new routes on use D RTF_DYNAMIC Created dynamically (by redirect) G RTF_GATEWAY Destination requires forwarding by intermediary H RTF_HOST Host entry (net otherwise) L RTF_LLINFO Valid protocol to link address translation M RTF_MODIFIED Modified dynamically (by redirect) R RTF_REJECT Host or net unreachable S RTF_STATIC Manually added U RTF_UP Route usable X RTF_XRESOLVE External daemon translates proto to link address
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
New routing capabilities have been added and affect the route(1C) command. Note the following new syntax:
ATTENTION -n was supported by the previous version too. It is given here for completeness.
The following options have been added to the route command:
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
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:
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 has been enhanced with the following options:
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 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 */ }
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
The following ioctls have been deprecated:
IP_ADD_RT
IP_DEL_RT
IP_FLSH_RT
IP_GET_RT
IP_DMP_RT
IP_DMP_MIB_RT
IP_ADD_SUBNET_RT
IP_DMP_SUBNET_RT
SIOCSARP
SIOCDARP
SIOCFARP
SIOCGARP
SIOCMGARP
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 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 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 (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 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
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.
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.
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.
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.
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.
The routing enhancements have caused changes in some ptx/ADMIN menus. Refer to the ptx/TCP/IP Administration Guide for more information.
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 PATHptx/ADMIN PathNetwork 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 PATHptx/ADMIN Pathptx/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).
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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
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.
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.
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.
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.
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.
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.
Before the installation, remove the /usr/options/tcp/inetd_conf directory, if present, from both the current root disk and the alternate disk to be used for the installation.
Before the installation, save your current /etc/inetd.conf file in case you need to restore it.
During the installation, you may need to modify the preview log for ptx/TCP/IP.
Carefully examine the CONFLICTS entries in the preview.log file that are generated by the ptx/INSTALL program. The default answers might not be what you want.
Files such as /etc/hosts, /etc/services/, and etc/hosts.equiv might have a value of REPLACE rather than SKIP. You will need to restore your original files after the installation or change REPLACE to SKIP for the CONFLICTS entries in the preview.log file during the installation to ensure that your host specific custom files are preserved.
Note that the files /var/tcp/ifaddrs and /var/tcp/routetab are always retained from the previous installation, regardless of their CONFLICT entries in the preview.log.
ptx/TCP/IP replaces the /etc/services file. If ptx/CLUSTERS is also installed on your system, this action will remove the ptx/CLUSTERS information from the file. To retain the information, you must change the preview log entry for /etc/services from CONFLICT-REPLACE to CONFLICT-SKIP.
If the preview log entry for /etc/inetd.conf is CONFLICT-REPLACE, change it to CONFLICT-SKIP.
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 -RThe corrected entry is as follows:
shell stream tcp nowait root /usr/etc/reshd reshd -RIf you do not make this change, remote resh services will not function.
The following documentation is available on the online documentation CD:
ptx/TCP/IP Overview
ptx/TCP/IP Administration Guide
ptx/TCP/IP Programming Manual
ptx/TCP/IP Sockets Manual
ptx/TCP/IP Sockets Manual
This section lists the following problem report summaries:
The numbers in parentheses identify the problems in the problem-tracking system.
This release of ptx/TCP/IP contains fixes for the following software defects:
(232685) ifconfig failed to set the broadcast address.
(244781) copy_rt_mib did not copy appropriate information for rt_nexthop.
(246716) The mib2agt did not handle E2BIG error returns from the SIOCGIFCONF ioctl.
(249846) ifconfigall unnecessarily took down and then rebuilt some interfaces.
(250398) A drop in performance in TCP_RR on 4K boundaries resulted from a problem with Nagle mode.
(250594) sendmail died on signal 8.
(250729) The telnet man page stated that only the csh shell supports job control. It now states that csh(1), ksh(1), and the unix98 sh(1) support job control.
(250736) The ptx/ADMIN menu to change the interface added the default broadcast address to the ifaddrs file.
(250782) By default, the system reports "TCP arp moved" messages in the ktlog. It is now possible to turn this feature off by setting the new kernel parameter ARP_NOTIFY_MAC_CHANGE to "false."
(250835) The mib2agt periodically dumped core, causing serious problems when the root filesystem was filled by the core file.
(250944) When t_advmaxseg was set to 0, t_maxseg was also set to zero. This resulted in a system panic when the system dealt with certain remote hosts.
(251195) MTU path discovery failed to increase the MTU once the MTU was lowered.
(251415) The mib2agt did not properly handle some ioctl failures.
(251417) The ARP cache was not completely updated as described in the ARP RFC.
(251473) A race condition in the telnet streams module led to a system panic.
(251503) syslogd did not use non-blocking writes to fifos and pipes.
(251764) A race condition in tcp timers led to a system panic.
(251959) The netstat -r command failed when large routing tables were used.
(252061) netstat -r returned the error "Not enough space."
(252079) An ifadmin attach operation on a non-streams device caused an MMU fault.
(252189) ifconfigall did not attach interfaces that were not in the ifaddrs file, causing ptx/CTC to fail.
(252195) routetab and other files were replaced by default when an updated version of ptx/TCP/IP was installed.
(252954) In a multi-homed host, dhcpd did not send packets out on the same interface that it got the packet from. Clients were therefore unable to boot from any of the networks.
(252990) The following panic occurred when ptx/SVM was running: Panicstr: 03: PANIC: soo_close loop:ptx/TCP.
(253230) The /etc/inetd listener limitation was not documented in the man page.
(253231) There was a limitation of 64 listeners (NFDS) for /etc/inetd that could not be changed by the user. There was also a limitation of 64 file descriptors (MAXFDS) that could be opened by /etc/inetd. The values for NFDS and MAXFDS have been increased to 256.
(253397) A rare race condition between incoming packets and lock processing could have caused a self-deadlock panic.
(253575) ifconfigall brought down SNAP interfaces (for example, FDDI and token ring).
(253598) An MMU fault occurred after a dupb() failure.
(253651) sockmod could lose output data on close.
(253702) When an attempt was made to delete a route, the error message "Bad value" was returned.
(253709) The system hung because of overlapping routes.
(253802) The TCP_MAXSEG setsockopt() function checked only that the value was greater than 0. It now checks that the value is greater than or equal to TCP_MIN_MSS.
(253827) The TCP_MIN_MSS function did not include enough space for all TCP options a user may want to send in addition to the standard header. The value for TCP_MIN_MSS has been changed to 61.
(254250) An invalid route was created for "hop > 10."
(254310) socketpair() returned incorrect information when errno was not set properly.
(254438) When an uninitialized ifconf structure was passed to the SIOCGIFCONF field, the process hung and error messages were displayed.
(254414) Fragmentation with IP options failed to be delivered.
(254445) The telnet client code incorrectly stated "DONT TRANSMIT-BINARY" twice for turning the binary mode off. It now includes "DONT TRANSMIT-BINARY" and "WONT TRANSMIT-BINARY."
(254478) The FTP client core dumped when it inherited more than twenty open file descriptors.
(254648) syslogd did not handle EINTR for output, which led to disabled logs.
(254779) New vulnerabilities existed in BIND V4.9.7 and V8.2.2.
(254825) During a cluster transition, the system panicked after a route flush command.
(255100) An MMU fault occurred when interfaces were added and deleted on a hostile kernel.
(255116) A treetop lock led to a deadlock when a memory failure occurred.
(255262) A panic occurred when the system tried to send a UDP packet with a length greater than 64 KB.
(255292) A panic occurred with the message: "Assertion failed" dl != head, TCP: ifaccel remove: ifa en."
(255387) There was root access security vulnerability in xntpd, as described in CIAC Bulletin L-071.
This section lists open problems in this release of ptx/TCP/IP:
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).
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.
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.
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.
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.
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.
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.
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.
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.
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"
netstat variable for packet traffic needs to be unsigned. Currently netstat output can be erroneous when packet counts become large.
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.