Domain/IX BSD4.2 TCP/IP Release Document
Software Version 3.1
Part No. 010231-A00
Revision 00
This document describes Domain/IX BSD4.2
TCP/IP Software Version 3.1, which
includes new versions of BSD4.2
applications software (found in /etc and
/usr/ucb).
Release documents for standard Domain
software and optional software products
are located in the system /doc
directory.
NOTE: This software release does not
constitute a new Domain/IX
release. Installation of the
Domain/IX BSD4.2 TCP/IP Version
3.1 software will not change your
Domain/IX version number.
APOLLO COMPUTER INC.
330 Billerica Road
Chelmsford, Massachusetts 01824
Copyright c 1988 Apollo Computer Inc.
All rights reserved. Printed in U.S.A.
First Printing: June, 1988
This document was formatted using the FMT tool distributed with the Domain
computer system.
Apollo and Domain are registered trademarks of Apollo Computer Inc.
UNIX is a registered trademark of AT&T in the USA and other countries. Ada
is a registered trademark of U.S. Government (Ada Joint Program Office).
3DGMR, Aegis, D3M, DGR, Domain/Access, Domain/Ada, Domain/Bridge, Domain/C,
Domain/ComController, Domain/CommonLISP, Domain/CORE, Domain/Debug,
Domain/DFL, Domain/Dialogue, Domain/DQC, Domain/IX, Domain/Laser-26,
Domain/LISP, Domain/PAK, Domain/PCC, Domain/PCI, Domain/SNA, Domain/X.25,
DPSS, DPSS/Mail, DSEE, FPX, GMR, GPR, GSR, NCK, NLS, Network Computing
Kernel, Network Computing System, Network License Server, Open Dialogue,
Open System Toolkit, Personal Super Workstation, Personal Workstation,
Series 3000, and Series 4000 are trademarks of Apollo Computer Inc.
Apollo Computer Inc. reserves the right to make changes in specifications
and other information contained in this publication without prior notice,
and the reader should in all cases consult Apollo Computer Inc. to determine
whether any such changes have been made.
THE TERMS AND CONDITIONS GOVERNING THE SALE OF APOLLO COMPUTER INC. HARDWARE
PRODUCTS AND THE LICENSING OF APOLLO COMPUTER INC. SOFTWARE PROGRAMS CONSIST
SOLELY OF THOSE SET FORTH IN THE WRITTEN CONTRACTS BETWEEN APOLLO COMPUTER
INC. AND ITS CUSTOMERS. NO REPRESENTATION OR OTHER AFFIRMATION OF FACT
CONTAINED IN THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO STATEMENTS
REGARDING CAPACITY, RESPONSE-TIME PERFORMANCE, SUITABILITY FOR USE OR
PERFORMANCE OF PRODUCTS DESCRIBED HEREIN SHALL BE DEEMED TO BE A WARRANTY BY
APOLLO COMPUTER INC. FOR ANY PURPOSE, OR GIVE RISE TO ANY LIABILITY BY APOLLO
COMPUTER INC. WHATSOEVER.
IN NO EVENT SHALL APOLLO COMPUTER INC. BE LIABLE FOR ANY INCIDENTAL,
INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT
LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATING TO THIS PUBLICATION OR
THE INFORMATION CONTAINED IN IT, EVEN IF APOLLO COMPUTER INC. HAS BEEN
ADVISED, KNEW OR SHOULD HAVE KNOWN OF THE POSSIBILITY OF SUCH DAMAGES.
THE SOFTWARE PROGRAMS DESCRIBED IN THIS DOCUMENT ARE CONFIDENTIAL INFORMATION
AND PROPRIETARY PRODUCTS OF APOLLO COMPUTER INC. OR ITS LICENSORS.
Reader_Notice
This document resides on line in the /doc directory. To print a copy of this
document, use the PRF command with the -npag and -pr switches.
prf <file_pathname> -pr <printer_name> -npag
iii
Contents
Section
CHAPTER 1 FEATURES OF DOMAIN/IX BSD4.2 TCP/IP RELEASE 3.1
1.1 Software Requirements. . . . . . . . . . . . . . . . . . . . . . . 1-1
1.2 Startup Procedure. . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.3 Copyright Notices. . . . . . . . . . . . . . . . . . . . . . . . . 1-2
1.4 Improvements to Tcp_Server . . . . . . . . . . . . . . . . . . . . 1-2
1.5 Improvements to the Routing Utilities. . . . . . . . . . . . . . . 1-2
1.6 Changes to Rwhod and Ruptime . . . . . . . . . . . . . . . . . . . 1-3
1.7 The Ping Program . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1.8 Improvements to the Socket Interface . . . . . . . . . . . . . . . 1-3
1.8.1 Support for Raw Sockets. . . . . . . . . . . . . . . . . . . 1-4
1.8.2 Performance Improvement for Locally Connected Sockets. . . . 1-5
1.9 Ethernet Trailers. . . . . . . . . . . . . . . . . . . . . . . . . 1-5
CHAPTER 2 SOFTWARE INSTALLATION PROCEDURES
2.1 Order of Software Installation . . . . . . . . . . . . . . . . . . 2-2
2.2 New Installation Information . . . . . . . . . . . . . . . . . . . 2-2
2.2.1 Choosing a Target Node . . . . . . . . . . . . . . . . . . . 2-3
2.2.2 Choosing a Source Area . . . . . . . . . . . . . . . . . . . 2-3
2.2.3 Improved Error Checking and Verification . . . . . . . . . . 2-3
2.3 TCP/IP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
CHAPTER 3 DOCUMENTATION
3.1 Tcp_Server Usage . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.1.1 The Debug Switch . . . . . . . . . . . . . . . . . . . . . . 3-2
3.1.2 Dynamic Routing Switch . . . . . . . . . . . . . . . . . . . 3-2
3.1.3 Ping Switch. . . . . . . . . . . . . . . . . . . . . . . . . 3-3
3.1.4 MAXTTL Switch. . . . . . . . . . . . . . . . . . . . . . . . 3-4
3.1.5 Window Size Switch . . . . . . . . . . . . . . . . . . . . . 3-4
3.2 Changes to Manual Pages. . . . . . . . . . . . . . . . . . . . . . 3-4
3.2.1 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
3.2.2 Routed . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.2.3 Rwhod . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
3.2.4 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
3.2.5 Netstat. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
3.3 Changes to Configuring and Managing TCP/IP . . . . . . . . . . . . 3-8
3.3.1 Changes in the TCP/IP Initialization Procedure . . . . . . . 3-8
3.3.2 Domain Network Types . . . . . . . . . . . . . . . . . . . . 3-10
3.3.3 Changes in TCP/IP Product Definitions. . . . . . . . . . . . 3-10
3.3.4 Configuring a TCP/IP Network Without the Hostmap Directory . 3-11
3.3.5 Changes to Tcp_server Switches . . . . . . . . . . . . . . . 3-13
3.3.6 Changes to Makegate Description. . . . . . . . . . . . . . . 3-13
3.3.7 Clarification of /etc/gateway Format . . . . . . . . . . . . 3-13
3.3.8 New Definitions of Physical Interfaces for Network Devices . 3-14
3.4 Clarification to Using telnet and ftp . . . . . . . . . . . . . . . 3-15
Contents iv
3.5 EtherBridge Requirement . . . . . . . . . . . . . . . . . . . . . . 3-16
CHAPTER 4 FIXES AND BUGS IN TCP/IP VERSION 3.1
4.1 Bug Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1.1 Fixes for Data Corruption Problems. . . . . . . . . . . . . . 4-1
4.1.2 Tcp_server Improvements . . . . . . . . . . . . . . . . . . . 4-1
4.1.3 Fixes for Routing Problems. . . . . . . . . . . . . . . . . . 4-2
4.1.4 Fixes for Window Problems . . . . . . . . . . . . . . . . . . 4-2
4.1.5 Fixes for Socket Problems . . . . . . . . . . . . . . . . . . 4-2
4.1.6 Initialization Problems . . . . . . . . . . . . . . . . . . . 4-2
4.1.7 UDP Problems. . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.1.8 FTP Problems. . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.1.9 Other Bug Fixes . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.2 Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
APPENDIX A FIXES AND BUGS IN VERSION 3.0
A.1 Bugs in Version 3.0 . . . . . . . . . . . . . . . . . . . . . . . . A-1
A.2 Bug Fixes Since Version 2.1 . . . . . . . . . . . . . . . . . . . . A-1
Contents v
CHAPTER 1
FEATURES OF DOMAIN/IX BSD4.2 TCP/IP VERSION 3.1
This chapter briefly describes the main features of the Domain/IX BSD4.2
TCP/IP Version 3.1 software release. These features include a new
recommended startup procedure, improvements to several TCP/IP server and
utility programs, the addition of the ping program, and improvements to the
socket interface, including support for raw sockets. Version 3.1 also
includes significant performance enhancements. Bug fixes included in this
release are described in Chapter 4.
1.1 Software Requirements
The tape containing the BSD4.2 TCP/IP Version 3.1 software also includes
software that must be installed as part of the Domain/IX product. Please
install the BSD4.2 TCP/IP tape, whether or not you plan to use the TCP/IP
software.
Domain/IX BSD4.2 TCP/IP Version 3.1 requires SR9.7 for proper operation of
tcp_server. Specifically, the Version 3.1 software contains a modified SR9.7
streams library, /lib/streams, which is necessary for all network send
operations. Note that installing SR9.7 does not change the Domain/IX Release
version number. You will still be running Domain/IX Release 9.5 under SR9.7.
1.2 Startup Procedure
In order to overcome the initialization problem of TCP-based servers not
coming up properly at node boot time, we recommend that you change the node
startup procedure to invoke tcp_server and other daemons from the /etc/rc
file rather than from the DM startup file. Section 3.3.1 of Chapter 3 of
this document includes directions for changing the node startup procedure
and sample command lines.
Version 3.1 1-1 Domain/IX BSD4.2 TCP/IP
1.3 Copyright Notices
After you have installed BSD4.2 TCP/IP Version 3.1, you will see a slight
change on the display. We have added copyright notices for Apollo Computer
and AT&T. Previously, when booting the operating system, it was possible to
enter your name and password slightly before the Display Manager had
displayed the log-in prompt. This "type-ahead" was not a supported feature,
and no longer works.
1.4 Improvements to Tcp_server
Changes to tcp_server include the addition of four new switches, which
increase functionality of the server process, a new syntax for specifying
switches to the server, and delayed acknowledgement for packets. The new
switches, which are described in greater detail in Chapter 3, are:
-r Initializes dynamic routing by invoking /etc/routed and by not
executing /sys/tcp/makegate, the program which creates a static
internal routing table.
-p Sets the gateway ping interval in seconds.
-t Sets the IP maximum TTL (time-to-live) parameter.
-w Sets maximum receive window size.
The syntax change affects the previous -debug and -version switches. They
have been changed to -d and -v, respectively, and a space is no longer
allowed between the debug switch and the value associated with the switch.
Tcp_server now forks (i.e., detaches from the window) after it is invoked
unless the -d switch is used.
In TCP/IP Version 3.1, delayed acknowledgement of packets is the default
condition. In Version 3.0, each incoming packet caused an ACK to be sent.
In Version 3.1, the ACK is delayed until the receiver can uncover 33% of the
maximum window it offers. However, in no case is the ACK delayed longer than
0.25 seconds.
Finally, to run the Version 3.1 tcp_server, you must use the /lib/streams
that is installed with Version 3.1.
1.5 Improvements to the Routing Utilities
Version 3.1 improvements to the routing utilities, route and routed, include
complete functionality for the routing daemon and additional commands which
allow better TCP/IP routing table management.
Domain/IX BSD4.2 TCP/IP 1-2 Version 3.1
/etc/route now includes commands to add priority and default routes to the
routing table. Routed will not change or delete routes added with route.
The routing daemon,routed, now handles subnet routing and transmission paths
that incorporate point-to-point links. Also, it enables gateways to external
networks to advertise a default route rather than individual routes to all
systems. Three new switches also have been added to improve performance and
facilitate debugging.
For more information about these changes to route and routed, see Chapter 3
of this release document and also the on-line Manual Pages.
1.6 Changes to Rwhod and Ruptime
Rwhod has been changed to take advantage of the Domain distributed file
system and to reduce contention for the rwho directory. Since on Apollo
networks, there is no need for every host on the network to maintain its own
/usr/spool/rwho directory, a change has been made to allow you to specify one
host per network who will write the information to a master /usr/spool/rwho
directory. All the other hosts link to that master directory in order to
access the information but do not write to the directory, reducing contention
for the directory. Specifically, at Version 3.1, rwhod will write to
/usr/spool/rwho only if that directory is local to the node, or if the
optional -w switch is supplied.
In addition, in a Domain internet, rwho information can be gathered from
hosts across the entire internet so that the rwho program will display
information even for hosts on remote physical networks. See Chapter 3 for
more information about using rwhod on Domain networks.
Ruptime no longer prints load average information. (At SR9.5, load average
information no longer reflected node status because load average values were
printed in all 0s.)
1.7 The Ping Program
Version 3.1 introduces the ping program, which sends Internet Control Message
Protocol (ICMP) echo requests to remote systems to determine whether the
systems are accessible through TCP/IP. See Chapter 3 for more information
about ping.
1.8 Improvements to the Socket Interface
Version 3.1 provides two improvements to the socket interface, support for
raw sockets and a performance improvement for locally connected sockets.
Version 3.1 1-3 Domain/IX BSD4.2 TCP/IP
1.8.1 Support for Raw Sockets
At Version 3.1, the socket interface supports the notion of 'raw sockets'. A
normal socket is used to read and write user data; a raw socket is used to
gain access to the underlying communications protocol headers. Raw sockets
allow network monitoring and debugging (through the Internet Control Message
Protocol, ICMP) as well as higher-level protocol development.
Raw sockets are datagram-oriented sockets. A program supplies the
protocol headers on a write, and receives the protocol headers on a read.
For IP family protocols, a program supplies the protocol header without the
IP header on a write, and the socket code adds the IP header before the
packet is sent. The socket code returns the complete protocol header to the
program including the IP header on a read.
A raw socket can also be opened for all IP protocols (protocol 0). For
sockets of this type, the program supplies the complete protocol header
including the IP header on a write. Reads on such a socket receive the
complete procotol header, just like reads on any IP family raw socket.
For example, to write to a raw socket opened for UDP, a program must supply
the UDP header as defined in /usr/include/netinet/udp.h. On a read, the raw
socket opened for UDP will return the IP__and__UDP headers as defined in
/usr/include/netinet/in.h and /usr/include/netinet/udp.h. The incoming UDP
packet is received by all processes with open UDP raw sockets, as well as by
any process with an open normal datagram socket.
To open a raw socket, use the socket(2) system call:
s = socket (AF_INET, SOCK_RAW, proto)
where AF_INET is the ARPA-Internet protocol family (in address format), and
proto is the the number for the protocol you want to access. Supplying a
protocol number of 0 specifies IP family protocols.
An incoming packet for protocol 'p' will be delivered to all processes with
raw sockets open for that protocol. A raw socket for IP will receive all
incoming packets for IP, UDP, TCP, and the other IP-family protocols. If an
incoming packet is subject to IP fragmentation, the IP checksum is 0xffff.
(Note that our TCP/IP implementation supports the raw socket interface for
the Internet Protocol family only.)
For more information about raw sockets, see the BSD4.2 Manual Pages for
socket(2), icmp(4p), inetd(4f), ip(4p), and route(8c). See also the following
sources as listed in the BSD System Index:
o intro(4n)-1
o PSI:6-33,37, PSI:8-3,28,30,38
o SMM:13-21..23, SMM:15-3..4,22..24
Domain/IX BSD4.2 TCP/IP 1-4 Version 3.1
Also refer to the BSD4.2 Interprocess Communications chapter in the
Domain/IX_Support_Tools_Guide (009413).
1.8.2 Performance Improvement for Locally Connected Sockets
Version 3.1 is optimized to improve the performance of sockets that are
resident on the same node. Basically, the data is passed directly between
processes without data copy, checksum calculation or verification, and
without involving the tcp_server process. This optimization improves the
performance of the X Window System running local applications. (There is no
performance improvement in X Window Systems running remote applications.)
(This optimization first appeared in SR9.6.)
1.9 Ethernet Trailers
You can now use /etc/ifconfig to cause TCP/IP to send Ethernet trailer
packets. See the Manual page for ifconfig(8c) for more information.
*X Window System is a trademark of MIT.
Version 3.1 1-5 Domain/IX BSD4.2 TCP/IP
CHAPTER 2
INSTALLATION INFORMATION
You can add Domain/IX BSD4.2 TCP/IP Version 3.1 to a user node (one equipped
with monitor and keyboard) or to a Domain Server Processor (DSP) that is
running SR9.7 or a more recent version of the Aegis or Domain/IX operating
system. If the user node or DSP is not running SR9.7 or a more recent
version, follow the appropriate software update procedures as described in
Installing__Domain__Software (Order No. 008860) or in the appropriate release
notes.
The user node or DSP must have a minimum of 980 blocks of available disk
space for a successful installation of this software.
NOTES: Domain/IX BSD4.2 TCP/IP Version 3.1 requires SR9.7 for
proper operation of tcp_server. Specifically, the
Version 3.1 tcp_server contains a modified SR9.7 lib
streams file, which is necessary for all network send
operations.
The following Domain/IX BSD4.2 programs and servers rely
on the presence of a properly configured SR9.7
tcp_server:
lpr(1) lpd(8) rcp(1)
rlogin(1) rlogind(8c) ruptime(1)
rsh(1) rshd(8c) inetd(8c)
ftp(1) ftpd(8c) rexecd(8c)
tftp(1) tftpd(8c) route(8c)
telnet(1) telnetd(8c) routed(8c)
rwho(1) rwhod(8c)
You must update nodes that will run TCP/IP to SR9.7
before you install Version 3.1.
If a Domain node containing the EtherBridge product is
being used as a TCP/IP gateway, all Domain nodes running
Version 3.1 2-1 Domain/IX BSD4.2 TCP/IP
TCP/IP on the 2 networks connected to that gateway must
be updated to TCP/IP Version 3.0, at least, for the nodes
to communicate through the gateway. However, we highly
recommend that you update all your TCP/IP nodes to
Version 3.1.
2.1 Order of Installation
Customers who are installing Domain/IX for the first time will receive
Domain/IX Release 9.5, which they must install after SR9.7 is installed.
Domain/IX BSD4.2 TCP/IP Version 3.1 must be installed after Domain/IX.
The order of software installation is:
1. SR9.7
2. Domain/IX Release 9.5
3. Domain/IX BSD4.2 TCP/IP Version 3.1
Installing SR9.7 does not change the Domain/IX Release 9.5 version number.
You will still be running Domain/IX Release 9.5 under SR9.7.
For general instructions on how to install this product, see Chapter 5 of
Installing_Domain_Software which describes installation of optional product
software. When you do a user installation, the installation program assumes
that the Domain/IX administrative node is also the TCP/IP administrative
node.
After installing the TCP/IP software for the first time and before rebooting
your node, you must edit the following files:
o /sys/tcp/thishost: add your node's name
o /sys/tcp/networks: add your node's physical interfaces
o /etc/inetd.conf: uncomment the services you want to run on your
node.
Templates for these files are located in the /sys/tcp directory.
2.2 New Installation Information
There have been some enhancements made to the installation procedure since
the publication of the last revision of Installing__Domain__Software; we
describe those changes here.
Domain/IX BSD4.2 TCP/IP 2-2 Version 3.1
2.2.1 Choosing a Target Node
The new installation sets the TARGET area by default to the current work
node. When you are prompted to enter a TARGET, the name of the current work
node appears as the default and can be selected simple by pressing the
<RETURN> key. For example:
The TARGET is the node or subdirectory on which you are installing
software (e.g., '//my_node' or '//my_node/subdirectory').
Enter Target: <//sum> <RETURN>
The program then confirms your choice of target.
TARGET set to : //sum
2.2.2 Choosing a Source Area
When you choose a source area, the program now confirms your choice by displaying it
on the screen. For example:
The SOURCE AREA is the node or subdirectory from which you are
copying software (e.g., '//node' or '//node/subdirectory').
Enter Source Area: //ergo
SOURCE AREA set to : //ergo
2.2.3 Improved Error Checking and Verification
After you have chosen the TARGET, the INSTALL program describes constraints
on the installation process, and asks if you wish to see a list of
directories affected by those constraints. If you choose to see such a
listing by typing 'yes' or 'y', the tool displays the list immediately, or
prints the message "No errors found." For example:
Version 3.1 2-3 Domain/IX BSD4.2 TCP/IP
NOTICE:
Objects will not be installed across
links, nor if unexpected objects currently
exist where directories are needed.
Would you like to see a listing of any
problems of this sort before proceeding?
Yes or No? y
-------------------------------------------------
Listing pathname errors found with TARGET set to //sum
(Please be patient)
//sum/sys/help
//sum/domain_examples
If you answered the question above with a 'yes' or 'y', and the program
displayed one or more 'pathname errors,' the program now describes the
warning messages about link objects that are generated during a later phase
of the installation. Enter 'yes' or 'y' at the prompt if you wish to see
error messages regarding installation of links. If you wish to suppress such
messages, enter 'no' or 'n.'
The program displays a warning message
whenever one of these objects is
encountered during the installation,
although the display of these messages
can be suppressed.
CAUTION : These objects will not be
installed, whether or not the warning
messages are displayed.
Do you want to see the warning messages?
Yes or No? y
2.3 TCP/IP Files
The installation program installs the following files on administrative nodes
and on host nodes that do not contain links to a master /etc directory.
//TARGET/bsd4.2/etc/route
//TARGET/bsd4.2/etc/routed
//TARGET/bsd4.2/etc/rwhod
//TARGET/bsd4.2/etc/ping
//TARGET/bsd4.2/etc/ftpd
Domain/IX BSD4.2 TCP/IP 2-4 Version 3.1
//TARGET/bsd4.2/usr/ucb/ftpd
//TARGET/bsd4.2/usr/ucb/netstat
//TARGET/bsd4.2/doc/tcp.release_notes
//TARGET/bsd4.2/sys/tcp/makegate
//TARGET/bsd4.2/sys/tcp/maphost
//TARGET/bsd4.2/sys/tcp/networks_template (hosts where the networks file
does not already exist)
//TARGET/bsd4.2/sys/tcp/tcpinit
//TARGET/bsd4.2/sys/tcp/tcpreset
//TARGET/bsd4.2/sys/tcp/tcp_server
//TARGET/bsd4.2/sys/tcp/telnet_server
//TARGET/bsd4.2/sys/tcp/thishost_template (hosts where the thishost file
does not already exist)
//TARGET/bsd4.2/usr/man/man1/netstat.1
//TARGET/bsd4.2/usr/man/man8/ping.8
//TARGET/bsd4.2/usr/man/man8/route.8
//TARGET/bsd4.2/usr/man/man8/routed.8
//TARGET/bsd4.2/usr/man/man8/rwhod.8
//TARGET/lib/streams
//TARGET/systest/ssr_util/dtcb
//TARGET/systest/ssr_util/mbd
//TARGET/systest/ssr_util/sodebug
//TARGET/systest/ssr_util/trpt
Version 3.1 2-5 Domain/IX BSD4.2 TCP/IP
CHAPTER 3
DOCUMENTATION
This chapter describes the usage of tcp_server and summarizes changes to
existing TCP/IP documentation caused by Version 3.1. The documentation
affected includes Domain/IX BSD4.2 Manual Pages and the user manuals
Configuring__and__Managing__TCP/IP (008543) and Using_telnet_and_ftp (008667).
These manuals have not been revised for TCP/IP Version 3.1.
Configuring_and_Managing__TCP/IP describes how to configure, manage, and
troubleshoot Domain TCP/IP and Domain/IX BSD4.2 TCP/IP.
Using__telnet__and__ftp describes how to use two common TCP/IP utilities: the
TELNET remote terminal emulator and the FTP file transfer program. This book
describes both the Domain and Domain/IX versions of these utilities.
Another document relevant to Domain/IX BSD4.2TCP/IP is System_Administration
for_Domain/IX_BSD4.2 (009355), which contains Domain/IX BSD4.2 Manual Pages
as well as a subset of information contained in Configuring_and_Managing
TCP/IP that is relevant to BSD4.2 TCP/IP.
3.1 Tcp_Server Usage
Version 3.1 introduces four switches for tcp_server and a new syntax for
specifying switch values. Note that tcp_server now forks at initialization
unless you specify the debug option, -d. Usage: tcp_server [-d<mask>] |
[-w<window>]| -r<routing server>
| -t | -u/-? | -v | [-p<time>]
-d<mask> Set debug mask. See table below for mask values.
-n Do not run tcpinit.
-p<time> Gateway Ping time in seconds. Express values in hex.
-r<routing server> Initialize using dynamic routing (i.e.,use /etc/routed,
do not execute /sys/tcp/makegate).
-t<ipttl> Set IP max time-to-live. Express values in hex.
-u/-? Print this text.
-v Print the TCP/IP version number.
-w<window> Set receive window size. Express values in hex.
Version 3.1 3-1 Domain/IX BSD4.2 TCP/IP
NOTES: The -d switch is changed from -debug and the -v switch
is changed from -version. The previous versions of these
switches are documented in Configuring__and__Managing
TCP/IP (008543).
Tcp_server requires lower case switches. Therefore, when
you start tcp_server with a DM command (e.g., cps
/sys/tcp/tcp_server), you must enclose the switches in
quotes to prevent the DM from converting them to upper
case.
The new syntax eliminates the space between the switch and the value
associated with the switch. The following command lines show the old and new
syntax to specify the tcp_server debug mask:
New (Version 3.1): tcp_server -d0001
Old (Version 3.0 and before): tcp_server -debug 0001
3.1.1 The Debug Switch
This switch forces the server to run in a window and requests the display of
debugging information as defined by the 16-bit mask. The table below
describes the debug information that can be requested. Add bit values
together to request several types of information.
Mask Information
_________ _________________
0001 (default) General information
0002 IP level information
0004 ARP information
0008 TCP information
0010 Data in TCP packets
0020 UDP information
0200 Broadcasts
1000 TCP finite state machine information
2000 Device level information
4000 Additional detail at any level
f0ff All available debug information
except broadcasts
ffff All available debug information
3.1.2 The Dynamic Routing Switch
When you use the -r switch, tcp_server
o Invokes the routing server specified with the switch, or the default
server, /etc/routed, and
Domain/IX BSD4.2 TCP/IP 3-2 Version 3.1
o Does not execute /sys/tcp/makegate.
When you do not use the -r switch, tcp_server
o Executes tcpinit, which reads the file /sys/node_data/networks whose
entries associate the node's network addresses with network physical
level interface identifiers, and
o Executes makegate, which initializes a static internal routing table
using the routing information in /sys/tcp/gateways.
(If no /sys/tcp/gateways file exists, makegate simply initializes the routing
table to be filled with information gathered by routed.)
We recommend that you use dynamic routing on TCP/IP gateways but that you
invoke routed separately from tcp_server in the startup file. For Domain
hosts, we recommend that you run routed with the -h option to allow the hosts
to gain up-to-date routing information. See section 3.3.1 below for examples
of the command lines you should add to the startup file `node_data/etc.rc to
invoke these processes correctly. On internets with only one Apollo gateway,
you may choose to use only static routing.
3.1.3 The Ping Switch
The -p switch causes tcp_server to send ICMP echo requests, at the specified
interval, to gateways which are in use by open connections on that device, to
determine whether they are functioning.
Using the -p switch can help to establish which gateways are available and
to convey information about unavailable gateways to the routing table. At
the specified interval, tcp_server issues an ICMP echo request to every
gateway in use by an active connection on that device. After three requests
with no response, the gateway is 'pinged out' and it is moved to the end of
the routing table. Tcp_server then uses an alternate route if one is
available.
The Version 3.1 tcp_server allows you to specify the ping interval in
seconds. The default value is 4 seconds. You may set the time to 1 second to
help trace a failing gateway or to improve routing performance when gateway
failures are frequent. You may inhibit pinging altogether by specifying a
0-second interval.
Version 3.1 also introduces the ping utility to facilitate network debugging
by sending ICMP echo requests to individual hosts. See below for more
information about this utility.
Version 3.1 3-3 Domain/IX BSD4.2 TCP/IP
3.1.4 The MAXTTL Switch
The Version 3.1 tcp_server supports a -t switch to set IP maximum
time-to-live (MAXTTL) to any desired value. The maximum time-to-live
indicates how long a TCP/IP packet will continue to be transmitted through
the network. In Version 3.0, the IP MAXTTL parameter default was 10; in
Version 3.1, the default is 30. Most TCP/IP implementations treat MAXTTL as
a hop-count and decrement the TTL field in packet headers by 1 when
forwarding packets. Thus, in effect, the new default means that a packet can
be transmitted across 30 gateways (or hops) before it will be discarded.
3.1.5 The Window Size Switch
With Version 3.1, users can set a maximum offered window size. This feature
allows for interoperation with third party vendor network devices, e.g.,
gateways, routers, bridges, and repeaters. The tcp_server process now
accepts a -w argument, so that the user can reduce the maximum offered window
size. The default value is 0x23B0 bytes. The user can set the value to
between 0x800 and 0x23B0 bytes. We recommend that users who desire maximum
throughput on their TCP/IP connections use the default maximum offered window
size. In some cases where users are experiencing buffering problems with
third-party repeaters, it may be useful to reduce the maximum offered window
size by using the -w switch.
NOTE: Exercise care in using this switch. We recommend that
you do not offer a window size less than 0x1000 bytes,
unless your Apollo service representative advises you
otherwise.
3.2 Changes to Manual Pages
TCP/IP Version 3.1 includes changes to four Manual Pages, netstat, route,
routed, and rwhod, and includes a new page for the ping program. You can
view the complete Manual Pages on line.
3.2.1 Route
At Version 3.1, several changes have been made to route, including the
addition of commands to add priority and default routes to the routing
table.
The Manual Page for route includes the following new information.
Usage: /etc/route [-f] cmd [net | host] gate [metric]
NOTES: Route requires you to supply a non-zero metric value.
Domain/IX BSD4.2 TCP/IP 3-4 Version 3.1
When adding routes to the routing table with route,
specify the gateway by means of its IP address on the
local network, not by its logical name.
The new commands added at Version 3.1 are listed below. Routes added
manually by route cannot be deleted by routed.
add default Add the specified gateway as a default route.
Tcp_server uses the default route when other routes
occuring earlier in the routing table have failed or if
no other possible route exists. To add a default route:
/etc/route add default gateway_addr [metric]
addp Add the specified gateway as a priority route. The
TCP/IP server process uses priority routes before default
routes or routes established by routed. A route added
with addp will appear first in the gateway table when it
is displayed with tcpstat -g or the Domain/IX command,
netstat -r). To add a priority route:
/etc/route addp gateway_addr [metric]
3.2.2 Routed
The routing daemon, routed, now handles subnet routing and transmission paths
that incorporate point-to-point links. Also, it enables gateways to external
networks to advertise a default route rather than individual routes to all
systems. Three new switches also have been added to improve performance and
facilitate debugging.
The Manual Page for routed includes the following new information.
Usage: routed [-s] [-q] [-t] [-g] [-n] [-f] [-h] <logfile>
The three new switches added at Version 3.1 are:
-n Directs routed not to install changes into the local routing table.
However, the routed process continues to receive broadcasts from
other routed processes. The -n switch is for debugging purposes.
-f Directs routed at startup to flush (purge) all routes from the local
routing table except routes added manually with /etc/route.
-h Stops the routed process after the routing table has stabilized. Use
the -h option on hosts only. Gateways must continuously run routed to
update routing tables.
Version 3.1 3-5 Domain/IX BSD4.2 TCP/IP
3.2.3 Rwhod
The Domain distributed file system allows you extra flexibility when running
rwhod on hosts in a TCP/IP internet. Normally rwhod updates files in a local
/usr/spool/rwho directory, and shows information only for hosts which are
directly connected to the same physical network. In the Domain system, you
can link /usr/spool/rhwo to an administrative/master node for rwhod. This
allows you to gather rwho information from hosts across an entire Domain
internet into /usr/spool/rwho, so that the rwho program will display
information even for hosts that are connected to remote physical networks.
In addition, since on Apollo networks, there is no need for every host on the
network to maintain its own /usr/spool/rwho directory, a change has been
made to allow you to specify one host per network who will write the
information to a master /usr/spool/rwho directory. All the other hosts link
to that master directory to access the information but do not write to the
directory. This change reduces contention for the /usr/spool/rwho
directory. Specifically, rwhod writes to /usr/spool/rwho only if that
directory is local to the node, or if the optional -w switch is supplied.
The Manual Page for rwhod includes the following description of the -w
switch.
-w Update the files in the /usr/spool/rwho directory, even if the
directory is not local to the node.
Note that rwhod will update the files in the /usr/spool/rwho directory in two
cases:
1. If the /usr/spool/rwhod directory is physically located on that
host.
2. If rwhod was started with the -w switch.
To reduce contention for the rwho directory and provide updated information
to hosts, we recommend that you
o Physically locate the /usr/spool/rhwo directory on the network's
TCP/IP administrative node. All other hosts on the network should be
set up so that /usr/spool/rwho is a link to the admin node.
o If you are running rwhod in a Domain internet, you can configure your
network in one of two ways:
1. Configure one node on each subnet to have a local
/usr/spool/rwho and link all other nodes on that subnet to
the /usr/spool/rwho directory on that node.
2. Configure all nodes in the internet to link to one master
TCP/IP administrative node containing the /usr/spool/rwho
directory. This enables the rwho and ruptime utilities to
Domain/IX BSD4.2 TCP/IP 3-6 Version 3.1
see all nodes in the internet.
In order to make this arrangement work, you must run rwhod -w
on one node on each subnet. They will then write their
subnet's information to the directory on the internet's
master TCP/IP administrative node.
3. You also can run rwhod on a gateway to see broadcasts from
two networks.
3.2.4 Ping
Version 3.1 has added the ping utility. This section contains information
from the Manual Page for the Ping program.
Usage: /etc/ping [ -r ] [ -v ] [____] [__________] [_____]
Many internets are large and complex aggregations of network hardware,
connected together by gateways. Tracking a single-point hardware or software
failure can often be difficult. Ping utilizes the ICMP protocol's mandatory
ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway.
ECHO_REQUEST datagrams (``pings'') have an IP and ICMP header, followed by a
struct timeval, and then an arbitrary number of ``pad'' bytes used to fill
out the packet. Default datagram length is 64 bytes, but this may be changed
using the command-line switch, packetsize. Other switches are:
-r Bypass the normal routing tables and send directly to a host on an
attached network. If the host is not on a directly-attached network,
an error is returned. This can be used to ping a local host through
an interface that has no route through it (e.g., after the interface
was dropped by routed(8C)).
-v Verbose output. ICMP packets other than ECHO RESPONSE that are
received are listed.
When using ping for fault isolation, first run it to to verify that the local
network interface is up and running. Then, use ping to contact hosts and
gateways further and further away. Ping sends one datagram per second, and
prints one line of output for every ECHO_RESPONSE returned. No output is
produced if there is no response. If an optional count is given, only that
number of requests is sent. Round-trip times and packet loss statistics are
computed. When all responses have been received or the program times out
(with a count specified), or if the program is terminated with a SIGINT, a
brief summary is displayed.
This program is intended for use in network testing, measurement and
management. It should be used primarily for manual fault isolation. Because
of the load it could impose on the network, it is unwise to use ping during
Version 3.1 3-7 Domain/IX BSD4.2 TCP/IP
normal operations or from automated scripts.
3.2.5 Netstat
Two new options and several new flags, which indicate the status of available
routes, have been defined for netstat. The flags are displayed when the
command is executed with the -r option. In addition, the -s option has been
improved and the way the -r option works has been changed.
The option definitions are:
-T Show all the status information collected by netstat.
-I Show status of physical interfaces. When used with the interval
argument, display a running count of the statistics.
-s This option now lists all the per-protocol statistics and the
routing statistics.
-r This option now lists only the routing table. Use the -s option to
show routing statistics.
The flags are:
U Indicates the route is up. (old)
G Indicates the route is to a gateway. (old)
D Indicates route was created dynamically by a redirect. (old)
P Indicates priority route. (new)
S Indicates static route added explicitly with route. (new)
X Route marked for deletion. (new)
3.3 Changes to Configuring_and_Managing_TCP/IP
This section contains new information about the TCP/IP products and
configuring procedures. The information in this section supercedes the
information in Configuring_and_Managing_TCP/IP, Revision 01. Keep a copy of
these pages with the manual for reference.
3.3.1 Changes in the TCP/IP Initialization Procedure
At TCP/IP Version 3.1, tcp_server now detaches from the invoking
window/process after it completes its initialization. This change was
introduced to fix the initialization problem of TCP-based servers failing to
Domain/IX BSD4.2 TCP/IP 3-8 Version 3.1
come up properly at node boot time. A user invoking the tcp server process
in a window will see the server fork and exit, unless the -d switch was
supplied when the server was invoked.
We recommend that you invoke tcp_server and other daemons from the /etc/rc
file, not from the DM startup file. Invoking servers from the /etc/rc file
helps ensure that servers initialize, fork, and terminate in the proper
sequence.
Currently, page 4-6 of the Configuring_and_Managing_TCP/IP manual contains
instructions for editing the DM startup file on each host to start
/sys/tcp/tcp_server and /etc/run_rc from that file. At Version 3.1, you
should
1. Delete from the node's DM startup file the lines that start
tcp_server and
2. Edit the /etc/rc file (`node_data/etc.rc) on_each_node to invoke all
TCP/IP services.
The following are examples of the new lines you must add to the /etc/rc
file. Add the appropriate lines and uncomment the command lines.
Do__not supply trailing &'s on any of the command lines to call a fork
routine. TCP/IP will not operate properly if you supply trailing &s.
For hosts and gateways that will run routed, use these command lines:
# for a host or gateway that WILL run routed
if [ -f /sys/tcp/tcp_server ]; then
/sys/tcp/tcp_server -n
fi
if [ -f /sys/tcp/tcpinit ]; then
/sys/tcp/tcpinit
fi
#
# invoke routed AFTER tcp_server and tcpinit (add -h option for hosts)
if [ -f /etc/routed ]; then
/etc/routed
fi
#
# run inetd on all hosts to manage ftpd, rshd, rexecd,
# rlogind, telnetd
if [ -f /etc/inetd ]; then
/etc/inetd
fi
#
# invoke other TCP/IP daemons, e.g., writed, talkd, lpd
For hosts and gateways that will_not run routed, use these command lines:
# for a host or gateway that will NOT run routed
Version 3.1 3-9 Domain/IX BSD4.2 TCP/IP
if [ -f /sys/tcp/tcp_server ]; then
/sys/tcp/tcp_server
fi
#
# run inetd on all hosts to manage ftpd, rshd, rexecd,
# rlogind, telnetd
if [ -f /etc/inetd ]; then
/etc/inetd
fi
#
# invoke other TCP/IP daemons, e.g., writed, talkd, lpd
NOTE: Invoke routed after invoking tcp_server and tcpinit.
NOTE: The parser for inetd.conf is sensitive to whitespace and
will ignore lines with leading whitespaces. This
behavior is consistent with other UNIX implementations.
3.3.2 Domain Network Types
Configuring_and_Managing_TCP/IP assumes that a Domain network is an Apollo
Token Ring network (ATR). As of SR9.6, a Domain network can be either an ATR
or an IEEE 802.3 network (commonly called an ETHERNET network). For more
information about IEEE 802.3 networks, see Planning__Domain_Networks_and
Internets (009916).
3.3.3 Changes in TCP/IP Product Definitions
Domain/IX sites no longer need to use the Domain TCP/IP optional software
package to obtain gateway support. The same gateway support is available in
BSD4.2 TCP/IP.
Prior to release 3.0, only the Domain TCP/IP optional software product
provided controller driver software for the gateway node's ETHERNET
controller. Since TCP/IP Version 3.0, driver software has not shipped with
the TCP/IP software. All driver software, with the exception of the
EtherController-MB, is now an integral part of the standard software
release.
EtherController-MB driver software is shipped with the controller. See the
EtherController-MB Release Document (009743) for information about installing
that software.
This change obsoletes the information on pages 3-4 and 3-5 of Configuring_and
Managing_TCP/IP.
To run Domain/IX BSD4.2 TCP/IP in a TCP/IP internet, you only need to create
the following files:
Domain/IX BSD4.2 TCP/IP 3-10 Version 3.1
/sys/tcp/thishost (a link to /sys/node_data[node_id]/thishost)
/sys/tcp/networks (a link to /sys/node_data[node_id]/networks)
/etc/hosts
/etc/networks
/etc/hosts.equiv (only for remote log-in privileges)
/etc/gateways (only if your internet includes hosts connected to
networks that don't support the Routing Information Protocol)
The BSD4.2 TCP/IP installation program will create the proper links.
Note that you do not need to create a local.txt file. Domain/IX BSD4.2
TCP/IP networks and internets can operate properly using the /etc/host file
instead of the local.txt file. These changes obsolete Steps 4 and 5 on page
5-6 of Configuring___and___Managing___TCP/IP, in which you create
/sys/tcp/hostmap/local.txt on the administrative node and run makehost.sh.
NOTE: If you do not wish to run routed on the gateways, the
next section contains instructions for editing the
/sys/tcp/gateways file.
3.3.4 Configuring a BSD4.2 TCP/IP Internet Without the Hostmap Directory
Under the old product definitions, the TCP/IP configuration procedures
included editing the /sys/tcp/hostmap/local.txt file and running the
/sys/tcp/hostmap/makehost.sh shell script to create several tcp_server data
files. The BSD4.2 TCP/IP software does not include the /sys/tcp/hostmap
directory, so Domain/IX customers must follow a different configuration
procedure. This procedure is supplied below.
1. Configure the /etc/hosts, /etc/networks, and /etc/gateways files.
For sites not on the ARPA-Internet, refer to part a. For sites on
the ARPA-Internet, refer to part b.
a) For sites not on the ARPA-Internet, edit the /etc/hosts,
/etc/networks, and /etc/gateways files to add your local
network information. Refer to the instructions on pages
3-14 and 3-15 in Configuring__and__Managing__TCP/IP for
information about the format and content of these files.
Then, go on to Step_2.
b) For sites on the ARPA-Internet, first create the
/etc/localhosts, /etc/localnetworks, and /etc/localgateways
files.
These files contain your local network information and
Version 3.1 3-11 Domain/IX BSD4.2 TCP/IP
should follow the formats described for /etc/hosts,
/etc/networks, and /etc/gateways on pages 3-14 and 3-15 in
Configuring_and_Managing_TCP/IP.
Next, use gettable to obtain a copy of the ARPA master host
file from the Stanford Research Institute Network
Information Center (SRI-NIC). The gettable program will
create a "hosts.txt" file in the current directory.
/etc/gettable sri.nic.arpa
Finally, use the htable utility to convert the information
contained in the hosts.txt and /etc/local... files into a
form that the TCP/IP software can use. The htable utility
creates three files in the current directory: hosts,
networks, and gateways. If the localhosts, localnetworks,
and localgateways files exist in the current directory,
htable automatically adds the local information from those
files to the top of the output files it creates.
/etc/htable hosts.txt
Refer to the gettable(8c) and htable(8) on-line Manual
Pages for more information. Then, go on to Step_2.
2. Provide each gateway with routing information. You can do this in
two ways: run routed on each gateway for dynamic routing or create
a /sys/tcp/gateways file on the administrative node with links on
each gateway for static routing. You only need the /sys/tcp/gateways
file if you do not run routed on the gateways. The tcp_server
process automatically looks for /sys/tcp/gateways, but does not
require it.
a) To configure each gateway to run routed, enter the
following lines in each gateway's Manual Pages
'node_data/etc.rc file:
if [-f /etc/routed]; then
/etc/routed
fi
b) If you do not wish to run routed, edit the
/sys/tcp/gateways file on the administrative node and link
each gateway to the file. Enter a line in the
/sys/tcp/gateways file for each gateway in the internet.
Follow the format shown on page 5-19 in Configuring__and
Managing_TCP/IP. The line must specify
- the gateway's IP addresses
- the gateway's name
Domain/IX BSD4.2 TCP/IP 3-12 Version 3.1
- the gateway's protocol
- the supported internet protocols; ip/gw for an IP
gateway, gw/prime for a gateway running routed,
and gw/dumb for a gateway that does not run
routed.
3. Execute makegate on each host. (Normally, makegate is started
automatically at tcp_server startup.) This program reads each line
in the /sys/tcp/gateways file and makes entries for local gateways
in the host's internal routing table. See page B-4 in Configuring
and_Managing_TCP/IP for more information about makegate.
3.3.5 Changes to Tcp_Server Switches
The tcp_server -debug and -version switches are now -d<mask> and -v. Note
that there is no longer a space between the switch and the bit value mask.
The functionality of these switches remains the same. The -debug and -version
switches are described on pages 7-3 through 7-5 in Configuring_and_Managing
TCP/IP.
3.3.6 Addition to Makegate Description
The makegate command is described on page B-4 of Configuring__and__Managing
TCP/IP. The following paragraph is a further clarification of the operation
of this command.
Makegate only accepts lines in the /sys/tcp/gateways file that describe local
gateways. Local gateways are gateways running on the same network as the
node running makegate. Makegate discards lines describing remote gateways.
Remote gateways are one or more hops away from the node running makegate).
Remote gateway information is picked up by the node via /etc/routed.
3.3.7 Clarification of /etc/gateway format
On page 3-14 of Configuring_and_Managing_TCP/IP, the format for lines in the
/etc/gateways is given. The following is a clarification of this format.
Each entry in the file is a single line in the following format:
<net|host> name1 gateway name2 metric hops <active|passive|external>
Where:
<net|host> Specifies type of routing destination, either net or
host.
name1 Specifies name or IP address of routing destination (net
Version 3.1 3-13 Domain/IX BSD4.2 TCP/IP
or host).
gateway Keyword that indicates following name (name2) is a
gateway.
name2 Specifies name or IP address of next gateway in route.
metric Keyword that indicates following field is number of hops.
If metric not specified, hop count is zero.
hops Number of gateways packets must travel through to reach
destination.
<active|passive|external> Indicates type of gateway name2 is. Active
indicates gateway runs routed. Passive indicates
gateways does not run routed. External indicates gateway
uses a protocol external to Routing Information
Protocol.
3.3.8 New Definitions of Physical Interfaces for Network Devices
On page 3-6 of Configuring_and__Managing__TCP/IP there are descriptions of
network physical interfaces and the way in which they are specified for each
node in its /sys/node_data[.node_id]/networks file. These descriptions have
changed with the introduction of the IEEE 802.3 network as a Domain network
type and with the implementation of shared routing and gateway applications
on a single network controller.
NOTE: In Domain/IX, BSD4.2 TCP/IP implementations need a
/sys/node_data[.node_id]/networks file on each host and
gateway. A template for this file is shipped on the
Version 3.1 media.
Please note the following changes to the descriptions on page 3-6:
dr0, dr1 Specify Apollo Token Ring (Domain ring) interfaces. A drn
interface can be a pre-SR9.6 Apollo Token Ring controller, an
A-NET-ATR, an IIC in a Domain/Bridge -A or -B con figuration,
or a COM-ECMB controller. The COM-ECMB controller is always
dr1 in an EtherBridge Domain router configuration.
eth0, eth1 Specify IEEE 802.3 Network (ETHERNET) interfaces. The ethn
interface can be an A-ADD-ETH, an A-NET-ETH, a V-NET-ETH, or a
COM-ECMB controller. The COM-ECMB controller is always eth0 in
a TCP/IP gateway configuration.
DN3000/DN4000 nodes can contain a maximum of four network controllers, but
only two of the same network type. Thus, you can have a gateway that
contains two Apollo Token Ring Controllers and two 802.3 Network Controllers
(dr0, dr1, eth0, and eth1), for example:
129.9.3.023 on dr0 ; Apollo Token Ring
Domain/IX BSD4.2 TCP/IP 3-14 Version 3.1
130.1.2.023 on dr1 ; Apollo Token Ring
149.8.5.023 on eth0 ; ETHERNET
150.2.3.023 on eth1 ; ETHERNET
A DSP90 gateway connected to an Apollo Token Ring and an ETHERNET network
through the EtherBridge product would appear in the networks file
/sys/node_data[.node_id]/networks as follows:
197.9.8.11 on dr0 ; Apollo Token Ring
149.8.5.023 on dr1 ; EtherBridge
Note that the dr1 interface can also apply to a Domain/Bridge-A or -B link or
to a second Apollo Token Ring network.
NOTE: If you have a node with an EtherController-MB, the
controller's device definition file (DDF) must be named
/sys/dev/ethernet0 in order for TCP/IP to run correctly
on that node. If the DDF file does not have that name,
change the name of the DDF using the chn command or
rebuild the DDF after you have installed SR9.7. This
information does not apply to nodes with AT- or VME-bus
controllers since they no longer require DDFs.
3.4 Clarification to Using_telnet_and_ftp
The Domain/IX ftp (/usr/ucb/ftp) Data Transfer Specification Commands allow
you to specify four types of data format (ascii, binary, image, and local)
but only one file structure (file). Ftp and ftpd use this information for
file transfer optimization only. Since UNIX does not support typed files in
the Aegis sense, all transferred files have the following attributes:
Ascii/Binary Flag = ascii
Type = uasc
However, when you use the Domain ftp (/com/ftp), which allows you to specify
four types of data format (ascii, binary, image,and local) with the Type
command and two file structures (file and record) with the Structure
command, the attributes of transferred files will differ depending on how
you use the Data Transfer Specification Commands and whether you are talking
to the Aegis ftp server, /sys/tcp/ftp_server, or to the UNIX server,
/etc/ftpd.
/com/ftp processes the Type command to be compatible with BSD UNIX
implementations of the ftp server. That is, although you can specify binary
format with the Type command, and the local host will treat the data as
binary, /com/ftp sends a Type image command to the remote server, since UNIX
ftp servers usually do not understand binary format type.
This action by /com/ftp results in non-symmetrical treatment of files between
Version 3.1 3-15 Domain/IX BSD4.2 TCP/IP
the local and remote hosts when you use the Type binary command. When you
get a file (and the file is created by the local host which thinks the format
is binary), the resulting file will be an obj file. When you send a file,
however, (and the file is created by the remote host which thinks the format
is image) the resulting file will be a uasc file. You must use the Type
local command in order to send obj files to a /sys/tcp/ftp_server.
The following table describes the file attributes of transferred files that
will result from various combinations of the /com/ftp Data Transfer
Specification Commands when the files are transferred by a node running
/com/ftp, from or to a remote node running the Aegis ftp server,
/sys/tcp/ftp_server.
Data Transfer || Resulting File Attributes
Specification Cmds || With Get Command || With Send Command
--------------------||-----------------------||----------------------
Structure| Type ||Ascii/Bin Flag| Type ||Ascii/Bin Flag| Type
---------|----------||--------------|--------||--------------|-------
| Ascii || ascii | uasc || ascii | uasc
|----------||--------------|--------||--------------|-------
| Binary || bin | obj || ascii | uasc
File |----------||--------------|--------||--------------|-------
| Image || ascii | uasc || ascii | uasc
|----------||--------------|--------||--------------|-------
| Local || bin | obj || bin | obj
=====================================================================
| Ascii || ascii | uasc || ascii | uasc
|----------||--------------|--------||--------------|-------
| Binary || bin | rec || ascii | rec
Record |----------||--------------|--------||--------------|-------
| Image || ascii | rec || ascii | rec
|----------||--------------|--------||--------------|-------
| Local || bin | rec || bin | rec
---------|----------||--------------|--------||--------------|-------
NOTE: Since UNIX does not support typed files in the Aegis
sense, when you use the UNIX command /usr/ucb/ftp on the
local host and transfer files from or to a remote host
running the UNIX server /etc/ftpd, all transferred files
have an ascii flag and uasc type.
3.5 EtherBridge Requirement
EtherBridge nodes with the dr1 interface normally route Domain packets over
the ETHERNET to another EtherBridge node with a dr1 interface. EtherBridge
nodes configured as TCP/IP gateways with an eth0 interface normally route
TCP/IP packets to a host on the ETHERNET with an eth0 interface.
Domain/IX BSD4.2 TCP/IP 3-16 Version 3.1
Domain packets dr1 ---> dr1
TCP/IP packets eth0 ---> eth0
Because both the dr1 and the eth0 interfaces are attached to the same
physical ETHERNET, you can assign the same IP address to both the dr1 and the
eth0 interfaces. In this case, however, TCP/IP packets may interpret the dr1
interface as a gateway to the ETHERNET. To ensure that TCP/IP packets are
properly routed through the eth0 interface, assign a unique IP address to
the EtherBridge link.
The EtherBridge link in the figure below has it own IP address: 192.3.8.
TCP/IP
Host
dr0 192.3.1
___|___
/ \
/ ring \
| 192.3.1 |
\ /
\_______/ TCP/IP
dr0 192.3.1 EB GW dr0 192.3.1 Host
dr1 192.3.8 | | eth0 192.3.3 eth0 192.3.3
____|___|________________________|______
| ETHERNET
dr1 192.3.8 | 192.3.3
dr0 192.3.2 |
___EB__
/ \
/ ring \
| 192.3.2 |
\ /
\_______/
Version 3.1 3-17 Domain/IX BSD4.2 TCP/IP
CHAPTER 4
FIXES AND BUGS IN DOMAIN/IX BSD4.2 TCP/IP VERSION 3.1
This chapter describes fixes and bugs in Domain/IX BSD4.2 TCP/IP Version
3.1. See Appendix A for fixes and bugs in Version 3.0.
4.1 Bug Fixes
This section describes the bug fixes included in Version 3.1. The fixes are
divided into several general topics.
4.1.1 Fix for Data Corruption Problems
o Data corruption problems caused by a faulty repacketization algorithm
have been corrected. These problems occurred infrequently during the
transfer of large files over noisy networks to some other vendors'
equipment.
4.1.2 Tcp_Server Improvements
o The Version 3.1 tcp_server process is more robust and will not
crash.
o A performance improvement that removed a data copy was added to
tcp_server.
o We now have Maximum Time-To-Live (MAXTTL) and ping interval
parameters for tcp_server that can be specified by the user.
o We now correctly handle Internet Type A addresses where the first
byte is 10 or 3 and the second byte is non-zero.
Version 3.1 4-1 Domain/IX BSD4.2 TCP/IP
4.1.3 Fixes for Routing Problems
o Routed now correctly handles broadcast packets.
o Routing code caused incorrect routing table entries for gateways
between networks with different address masks (e.g., Class A and
Class B) or between subnetted and non-subnetted networks. This
problem has been fixed.
o The routing table now handles up to 512 routes.
4.1.4 Fixes For Window Problems
o We no longer timeout a connection when the remote host is sending
0-windows.
o We now send one-character data packets, known as 0-window probes, at
intervals which range from 2 to 30 seconds.
o We now ACK 0-window probes.
4.1.5 Fixes to Socket Problems
o The problem of user applications (e.g., ftp, telnet) hanging or
crashing when tcp_server needed to manage large numbers of sockets
quickly has been fixed.
o Socket connections no longer hang on client nodes.
o A bug in Version 3.0 that affects error status returns from socket(2)
calls has been fixed in Version 3.1. (This bug fix first appeard in
SR9.6.) Some transient errors were returned more than once in Version
3.0. In Version 3.1, transient errors are returned by the socket
interface only once. Permanent error conditions are reported on
every call.
o Version 3.1 allows a program to reconnect to a connected datagram
socket. The socket is reconnected to the new target socket address
(sockaddr). However, a second connect(2) to a stream socket returns
an error. (This feature first appeard in SR9.6)
Domain/IX BSD4.2 TCP/IP 4-2 Version 3.1
4.1.6 Initialization Problems
o The problem of properly synchronizing the startup of TCP/IP servers
was partially fixed by causing the tcp_server to detach from the
window at startup. To ensure proper initialization, users must change
their startup files as suggested in Section 3.3.1 of this
document.
4.1.7 UDP Problems
o A bug in Version 3.0 that affects IP User Data Protocol (UDP) -based
server processes (such as routed and rwhod) has been fixed in Version
3.1. This bug caused some incoming UDP datagrams to be discarded,
even though a socket was open on the port to which they were
addressed, if the process owning the socket was calling sendto() at
the time the incoming datagrams arrived.
o UDP reads and writes up to 8K bytes are now allowed.
4.1.8 FTP Problems
o Multiple bugs that caused ftp sessions to hang have been fixed.
o Hash marks now are printed during data transfer when requested with
the ftp hash option.
o Using mget to get non-existent files no longer causes ftp to crash.
4.1.9 Other Bug Fixes
o The socket ioctls for SIOCGPGRP (get process group) and SIOCSPGRP
(set process group) do not work at TCP/IP Version 3.0. The process
group is not set or returned correctly. Use of the SIOCGPGRP ioctl
actually returns 8 bytes of information to the caller, which
improperly overwrites part of the caller's data area. These ioctls
are fixed in TCP/IP Version 3.1.
o You can now receive asynchronous notification of pending input on a
socket by establishing a signal handler for SIGIO. You must call
ioctl (s, FIOASYNC, &on)
Note that fcntl (s, F_SETFL, FASYNC) does not work. You must use the
Version 3.1 4-3 Domain/IX BSD4.2 TCP/IP
ioctl so that input on the socket generates the SIGIO signal.
o You can now use /etc/ifconfig to cause TCP/IP to send Ethernet
trailer packets.
o Rwho now reports all users logged on to the ring.
o TCP/IP now accepts all valid broadcast addresses.
o /sys/tcp/setroute supports gateway.g_flags GWSTATIC, GWPRIMARY
o In Version 3.1, large ICMP packets (e.g. ICMP echo requests) are
fragmented as required.
o Version 3.1 recognizes the "dr1" physical interface type. This fix
allows Version 3.1 to support TCP/IP in a Domain internet
environment. This capability was not properly supported in Version
3.0. See Chapter 3 for descriptions of the physical interfaces.
o The inetd process no longer hangs if tcp_server process is killed.
Previously, the kill -9 command caused inetd to hang. (This fix first
appeard in SR9.6.)
o Multiple problems that caused X windows to hang have been fixed.
o Bug that caused tcpreset hang has been fixed.
o A fix to the DSEE code is included in this release of TCP/IP.
Interbase users who used DSEE to build software received the error
message "EOF reached but not expected" from the Interbase GFRE
pre-processor while building a reserved element. This bug has been
fixed.
o Bug that caused TCP to hang if you <ctrl>-Q'd out of an FTP session
has been fixed.
o Htable now handles the new, larger NIC tables.
4.2 Bugs
o Under tcp3.1, urgent data is not handled correctly on LOCAL
connections, i.e. on connections to an address assigned to one of my
local interfaces. Urgent data to address 127.0.0.1, LOCALHOST, is
handled correctly. This will be fixed in an upcoming release.
o The parser for /etc/inetd.conf is sensitive to whitespace and will
ignore lines with leading whitespaces. (Note that this is consistent
with other Unix implementations.)
Domain/IX BSD4.2 TCP/IP 4-4 Version 3.1
o The -d switch for ftpd does not function because ftpd can only be
invoked by inetd which runs it as a background task.
o The /usr/ucb/ftp commands mdir and mls are not supported. Use the
commands ls or dir and pipe the output to a file.
o The usr/ucb/ftp command rename, when given a non-existent name,
causes the next ftp command to issue the error message "500 Command
not understood." The next command given, however, works properly.
o The usr/ucb/ftp command glob and the -g option do not disable file
name globbing as documented.
o When a telnet connection is made to a Cray 2 computer from an Aegis
or Unix window, keystrokes are not echoed unless you use the VT100
emulator.
o When the Aegis ftp and telnet server processes are started on a DSP
(running spm instead of dm), they have an extra uid associated with
them.
o Previously, when booting the operating system, you could enter your
name and password slightly before the Display Manager displayed the
log-in prompt. This "type-ahead" was not a supported feature and no
longer works.
o You must set the acls on /sys/node_data so that files get created
with open acls. If your sys/node_data acls are restricted,
/sys/tcp/tcp_server will not be able to create necessary data files.
Version 3.1 4-5 Domain/IX BSD4.2 TCP/IP
APPENDIX A
FIXES AND BUGS IN RELEASE 3.0
This appendix documents known bugs and fixes in the Version__3.0__TCP/IP
product for the benefit of users updating to Version 3.1 from Version 2.1.
A.1 Bugs in TCP/IP Version 3.0 Software
The following bugs existed in the TCP/IP Version 3.0 software:
o If you send two telnet ip (^ip) commands in a row, with no
intervening input, the second one is received by the foreign host as
the character 't'.
o The telnet ^S sequence and ^Q sequence do not work well because
Domain TCP/IP allows the remote system to transmit up to 8K bytes of
data at a time for performance reasons.
A.2 Bug Fixes Since Version 2.1
The following TCP/IP bugs have been corrected since TCP/IP Version 2.1:
o Version 3.0 supports Trailer Encapsulations as defined by Request for
Comment (RFC) 893, so you can communicate with TCP/IP implementations
that support trailers. This version corrects a problem with trailers
that occurred in Version 2.1.
o Prior to this release, the telnet_server and ftp_server would try to
initialize before the tcp_server started running and so the servers
failed to start. Version 3.0 corrects this problem. The
telnet_server and ftp_server now wait until tcp_server is running
before they start initializing.
o The telnet_server now negotiates echo switches correctly.
o Version 3.0 fixes a problem with the telnet_server that caused it to
Version 3.1 A-1 Domain/IX BSD4.2 TCP/IP
hang if you tried to log in to a Domain TCP/IP node, but exited
before you completed the log in procedure.
o Prior to this release, if you passed a bad data buffer address to a
get or put operation, the tcp_server would hang and become
unuseable. Version 3.0 corrects this problem.
o telnet now exits (correctly) when the other side resets the
connection.
o If you logged in from a remote host to a Domain node running Domain
telnet and then tried to run in a C shell, the C shell would hang.
Version 3.0 corrects this.
o If you logged in to a remote system using telnet, and the other side
sent null characters, the null characters would show up as triangles
on our side. Version 3.0 now ignores null characters, so you won't
see any triangles.
o Version 3.0 can now handle TCP/IP windows larger than 32K bytes.
o The rip_server would sometimes stop working properly after it had
been running for a while. That is, it would be running, but wouldn't
do anything. Version 3.0 corrects this.
o Conditional put operations of 4K bytes or more wouldn't work at
times. Version 3.0 corrects this.
o For BSD4.2 TCP/IP users, you can now specify a backlog of 0 in a call
to listen(). This is equivalent to setting a backlog of 1.
Domain/IX BSD4.2 TCP/IP A-2 Version 3.1