2000 The KA9Q Internet Software Package VERY Preliminary Version! December 28, 1987 by Bdale Garbee, N3EUA using material from Phil Karn, KA9Q Brian Lloyd, WB6RQN and suggestions from many others Copyright 1987 by Bdale Garbee. All Rights Reserved. This Document may be reproduced in whole or in part for any non-commercial purpose, as long as credit is given the authors. - 2 - 1. Background and Overview 1.1. What's TCP/IP All About? Charles Hedrick of RUTGERS, the State University of New Jersey, has written a very important document... a description of the "world of TCP/IP" that manages to be both a reasonable introduction for the non-technical or mildly technical individual, and an excellant starting point for anyone interested in learning more about the family of networking protocols commonly referred to as "TCP/IP". The only difficulty with this document for those who are trying to learn more about TCP/IP in the Amateur Radio "Packet" environment, is that the experience Mr. Hedrick works from is almost entirely with the wired networks common in universities and businesses, where various computer systems are networked together using some form of wire (usually coaxial cable as in Ethernet, or fibre optic cabling as in Pronet). The individual who is familiar with radio transmission will easily recognize differences between the wired environment and the on-air environment. This does not mean that the protocols are unfit for use on the air, it simply means that we need to be careful when *implementing* the protocols in software for use on the radio that we don't make assumptions that aren't valid on the air! In particular, wired networks allow the assumption that every host can hear every other host on the wire... quite unlike the situation in radio, where one-way propagation paths are often the norm. Mr. Hedrick mentions several protocols that can "ride on top of" TCP, such as Sun's Network File System, NFS. Some of the applications that he talks about, including NFS, while wonderful on wired networks, are somewhat unreasonable for packet radio until or unless we have *much* higher speed modems. Wired networks can easily run at 10 million bits per second, while packet ranges from 300 bits per second on HF, to perhaps 56 thousand bits per second with the WA4DSY modems on UHF. Therefore, some of the protocols such as NFS that like to eat lots of network bandwith won't be as neat on current packet radio as they are on current wired networks, but they certainly provides a dramatic improvement in potential services for the "next generation" of packet radio. The KA9Q Internet Package is currently the most common TCP/IP implementation (if not the only one!) in use on Amateur Packet Radio. The software supports the IBM PC and clones, the Apple Macintosh, the Commodore Amiga, and both BSD and System 5 Unix variants. The package provides IP, ICMP, TCP, UDP, and ARP as basic services, and implements the FTP, Telnet, and SMTP protocols as applications. The package also includes a separate mail user interface pro- gram by N3EUA called BM, and software from WA3PXX for forwarding PBBS mail over TCP. An associated set of software packages provide replacement ROM firmware for several TNC's, allowing them to be used with the KA9Q TCP/IP Package. At least two commercial manufacturers, AEA and Kantronics, now sup- port the KISS protocol in their TNC's, making them useable with TCP/IP. Charles Hedrick's excellant introduction to TCP/IP can be found in the same place you found this document, named TUTORIAL.DOC. If you're new to all this, go find and read that before you get too wound up in the bits... - 3 - 1.2. What's In the KA9Q Package This is an overview of the various modules making up the KA9Q Amateur Radio Internet Protocol package. Each section first describes the protocol that is supported, followed by a description of the implementation. 1.2.1. Subnet Layer 1.2.1.1. Standard 10 megabit Ethernet The driver provided is for the 3-Com 3C500 (IE) controller for the PC. Tight (3 instruction) assembler loops are used instead of DMA for copying data in and out of the controller's buffer; this seems fast enough. Only the receiver is interrupt driven; incoming packets are placed on a queue which is then emp- tied at a more leisurely pace by the main loop code. Since Ethernet is so fast, the transmitter routine busy-waits for completion. The IE controller has only a single buffer which is shared between receive and transmit. Packets occasionally get lost under heavy load, especially when several TCP connec- tions are active at once and/or the TCP receive window sizes are larger than the MSS values. This is very hard to fix without going to a newer, more rea- sonably designed controller. 1.2.1.2. Serial Line IP (SLIP) SLIP is a very simple technique for sending Internet Datagrams across ordinary asynchronous lines (e.g., modems). Its only function is to delimit datagrams with framing characters, which are "byte stuffed" for transparency. No error checking is provided; the checksums that are part of IP, TCP and UDP are relied on for this. SLIP is popular on UNIX systems that support TCP/IP, so this represented the easiest way to get my package up and talking with other Internet sites. It also allows the use of existing AX.25 TNCs without modify- ing the latter, although this is should only be done as a stopgap measure until an HDLC link level driver can be integrated directly into the package. 1.2.1.3. AX.25/KISS TNC Sends and receives IP and ARP datagrams encapsulated in AX.25 Unnumbered Information (UI) frames. This allows an unlimited number of simultaneous users on the local radio channel, since there are no connections at link level. The special AX.25 Level 3 Protocol ID values of hex CC (IP) and CD (ARP) are used. With the 871225.0 release, support has also been added for encapsulating IP datagrams in "normal" AX.25 connected-mode packets. This was a natural by- product of adding full AX.25 level 2 session support to the package. This mode of operation requires that the TNC run special "KISS TNC" code. Ver- sions for the TNC-2, TNC-1, and VADCG/ASHBY boards are included in this dis- tribution. Some manufacturers, including AEA and Kantronics, are adding sup- port for KISS into their commercial TNC products. Note that this style of operation is NOT compatible with a "stock" TNC carrying SLIP formatted datagrams in connected mode. - 4 - 1.2.1.4. AX.25/PACCOMM PC-100 Interface (NOT YET WORKING) The PC-100 is an I/O adapter card for the PC containing a Zilog 8530 Serial Communications Controller and two AMD 7910 World Chip modems. The encapsula- tion method is identical to (and compatible with) the AX.25/KISS TNC interface driver. 1.2.1.5. AX.25/Eagle Interface There is a card available at some swapfests made by Eagle Computer Company that implements two ports using the Zilog 8530. External modems are required. This driver is very similar to (and may eventually be merged with) the PC-100 driver. 1.2.1.6. Address Resolution Protocol (ARP) ARP is used for the automatic mapping of IP addresses to link or subnet addresses. While originally designed for the specific task of mapping IP t 2000 o Ethernet addresses, the protocol is general enough to be used on any link or subnet that supports a broadcast facility. ARP is described in ARPA RFC-826. Both Ethernet and AX.25 format addresses are currently supported. Instead of discarding a packet when an ARP request is sent, this implementation holds it on a queue for a limited time, pending a response to the request. 1.2.2. Internet layer 1.2.2.1. Internet Protocol (IP) IP is the universal network-level datagram protocol of the ARPA Internet. It corresponds roughly to level 3 of the ISO Reference Model (ISORM). (Actually, IP belongs to the 3B internetwork sublayer if you follow the amoeboid proli- feration of ISO sublayers). Routines are provided to generate, receive and route (i.e., packet switch) IP datagrams. IP is specified in ARPA RFC-791 and MIL-STD-1777. IP datagram fragmentation and reassembly is fully implemented. The IP options Loose Source Routing, Strict Source Routing and Record Route are supported; Stream ID, Security and Timestamp are ignored. (Few, if any, IP options are used extensively in the ARPA Internet). The IP module includes a routing (packet switching) facility; currently this consists of a table containing a list of host-specific destinations along with a "default" entry that may be used when the desired destination is not found in the table. No protocol is yet provided to actually manage the table; currently it must be done manually, either locally or remotely. NB! "Networks" (in the ARPA Class-A/B/C sense) are not yet understood, in that all entries in the routing table (except for the default entry) must be host-specific. This will be fixed in the future with a "generalized subnetting" scheme that will allow each entry in the table to have an arbitrary, variable length "subnet mask." 1.2.2.2. Internet Control Message Protocol (ICMP) ICMP is the error reporting adjunct to IP. It appears as a pseudo-protocol on top of IP, but is actually considered to be part of IP. The IP routines - 5 - automatically generate ICMP messages whenever an error occurs in the process- ing of IP datagrams; incoming ICMP messages are passed up to the originating end-to-end protocol for appropriate action. ICMP is specified in ARPA RFC-792. This ICMP supports all options except ICMP Timestamps. 1.2.3. Host-Host Layer 1.2.3.1. Transmission Control Protocol (TCP) TCP provides a reliable, sequenced "virtual circuit" or "connection-oriented" service atop IP on an end-to-end basis. It corresponds to the Transport layer (level 4) of the OSI model. Since a single TCP module supports multiple con- nections through the use of port numbers, it also provides Session (level 5) functionality without the need for a distinct layer. (Or it makes the session layer unnecessary, depending on your point of view). TCP is specified in ARPA RFC-793 and MIL-STD-1778. The implementation supports an arbitrary number of simultaneous connections, limited only by memory space for control blocks. An "upcall" mechanism is available to notify the user of three events: connection state change, receive data available and transmit buffer space available. The Maximum Segment Size option is understood and used when it is received, and a global variable is used for generating MSS in outgoing segments. There is currently no provision for sending URGent data. The latest recommendations on "tinygram" avoidance (Nagle, ARPA RFC-896) are implemented and work quite well. 1.2.3.2. User Datagram Protocol (UDP) UDP provides only a simple, unguaranteed "datagram" or "connectionless" ser- vice, adding only checksums and port multiplexing to the raw service provided by IP. As an alternative to TCP, UDP also sits at level 4 (and 5) of the ISORM. UDP is specified in ARPA RFC-768. The implementation supports the creation of queues on local sockets. An upcall mechanism similar to that used in TCP notifies the user when datagrams have arrived. 1.2.4. Application Layer 1.2.4.1. File Transfer Protocol (FTP) FTP is for transfer of binary or text files between hosts. FTP uses two TCP connections - one for exchanging commands and responses in the form of ASCII strings, and the other for the actual data transfers. FTP is defined in ARPA RFC-959. FTP is implemented in two parts, a server half and a client half. The server half supports multiple simultaneous remote users, although at the moment there is no access control; anyone may access, delete or overwrite any file on the machine. The client half is invoked by the "ftp" command. - 6 - 1.2.4.2. Remote login protocol (Telnet) Telnet is for logging into remote systems and negotiating various options, such as remote vs local echoing. Telnet itself is documented in ARPA RFC-854, with the many options defined in other RFCs. The client half supports the ECHO and TRANSMIT-BINARY options; it is invoked by the "telnet" command. A telnet "server" has been written, but since MS-DOS isn't a timesharing system it is used for keyboard-to-keyboard conversations instead. An incoming connect request to the local Telnet port creates a local Telnet session and notifies the local user. He may then select the new session and carry out a conversation with the remote initiator. 1.2.4.3. Simple Mail Transfer Protocol (SMTP) As the name implies, is used for the transfer of electronic mail between hosts. SMTP commands and responses are strings of ASCII characters resembling those used by FTP. SMTP uses a single TCP connection for both control and the actual mail messages. SMTP is described in ARPA RFC-821; headers in mail mes- sages are described in RFC-822. A simple version server (receiver) is implemented; it accepts mail from a remote sender and appends it to a mailbox. Mail forwarding, which accounts for much of the complexity in other mail servers, is not implemented. A mail client ("user agent") for composing and sending messages developed by Bdale Garbee, N3EUA, and others is included. It is called 'BM', and is documented elsewhere. 1.2.5. Session control The user may manage several simultaneous Telnet and FTP client invocations. Only one client session is "active" at any one time, but the user may quickly switch between them. Terminal output arriving for an inactive session is held until that session is again made active. (Note that this is in addition to the multiple server sessions which go on automatically "in the background", i.e., without operator intervention). The Internet package has been tested with and works under DoubleDos 4.0 by SoftLogic Solutions, allowing the system to be simultaneously "on the net" while executing conventional MS-DOS commands. The net program uses the spe- cial DoubleDos function call 0EEH to relinquish the processor when it isn't needed; this speeds up the task running in the other partition. This function is a "no-op" when DoubleDos isn't active. 2. Administrivia 2.1. What an "IP Address" is and How to Get One IP Addresses are 32 bit numbers that uniquely identify a given machine (or "host") running the TCP/IP protocol suite. All of the possible 32 bit numbers are coordinated by an entity known as the Network Information Center, or NIC. Amateur Radio operators are fortunate in that a "Class A Subnet" consisting of 24 bits of address, in the range 44.X.X.X, has been reserved for our use. By general concensus, Wally Linstruth WA6JPR of Santa Barbara, CA, now serves as - 7 - the top level administrator of the 44.X.X.X address space, and assigns blocks of addresses to regional coordinators from around the world. You need to have a unique address before you can link in with the rest of the networked world. 2.2. Obtaining Software Updates The KA9Q Internet software package is still evolving and growing. As a result, we occasionally issue updates to the software that fix bugs and/or update functionality. Announcements are always made to the USENET news group rec.ham-radio.packet, and in the bulletins on N3EUA's telephone BBS system. They usually also show up on Compuserve within a day or two. There is never any charge for the software. A small charge may exist for copying floppies if you want the bits on disk, and of course you'll have to pay the long distance if you grab the bits over the phone! If several people are running the software in your area, get together and decide on one person to get the new bits, then copy it around. We won't mind. 2.2.1. From N3EUA's Phone BBS The HIP Shack phone BBS, running Opus software, is reachable as Fidonet node 128/19, 303/495-2061. The BBS supports 300, 1200 and 2400 baud, is up 24hrs/day, and is configured to allow first-time users more than sufficient time to download the entire package in one phone call at 1200 baud. The BBS is always the first place that the software is available. Beta- release executables for the PC can also occasionally be found here. You down- load and use these at your own risk! (Known as the "you get what you pay for" principle). 2.2.2. From N3EUA's Unix Machine For those running Unix machines with UUCP capability, there is an anonymous UUCP login on winfree, N3EUA's BSD Unix machine, that can be used to download the software. This machine is up 24hrs/day, but only has one modem, and the modem stays fairly busy. A typical L.sys entry might be: winfree Any ACU 2400 1-303-495-0492 ogin: Uanon word: notFTP Start by transferring the file /usr/spool/uucppublic/pub/README for a list of the files available, and current release notes. 2.2.3. Via FTP on the Internet The current revision of the software is available on SIMTEL20.ARPA within a few days of each release. The files usually reside in the directory PD:. Questions on the files on Simtel20 can be directed to W8SDZ@SIMTEL20.ARPA. Anonymous FTP's are allowed. - 8 - Beta-releases are often available on the machine LOUIE.UDEL.EDU, in the direc- tory tree rooted at pub/ka9q. Anonymous FTP's are allowed, but unless you're working on the software, the bits on louie can be "dangerous", as they often include incompletely implemented features, and can have serious bugs. Caveat Emptor. 2.2.4. On PC Floppies The Tucson Amateur Packet Radio association (TAPR) now provides floppy copies of the software on 360k PC floppies, and can provide KISS ROMs for various TNC's, at a nominal charge for duplication and shipping. Contact TAPR for more information. 2.2.5. On Native Media for Other Machines Copies of the software for the Macintosh and Amiga are best obtained by down- loading from an online source, or by copying a friend's disk. If all else fails, Mikel Matthews (the author of the Mac/Amiga port) is willing to make a small number of copies on native media for the Mac and/or Amiga. Mikel can be reached via UUCP mail at ...uiucdcs!addamax!mikel. 3. Installation of the Software Installing the KA9Q Internet Package on your computer is not very hard, but if you haven't tried to do it before, it can be a bit confusing. The greatest efforts made so far towards making the process simple and understandable have been made by Brian Lloyd, WB6RQN. Much of this installation section is a direct copy of portions of his HOWTO.DOC document. Information about instal- lation on machines other than the IBM clone family has come from various sources. 3.1. Configuring Your TNC for Network Operation: If you are using this software in a University or other wired-network environ- ment, you may want to skip past the TNC installation section. All Hams should keep reading! There are now several choices for TNCs to be used with the TCP/IP network code. Versions of the Keep It Simple Stupid TNC interface software (KISS) are available for the TNC-1, the TNC-2, the VADCG board and clones (Ashby), the Kantronics family of TNCs, and the AEA TNCs. Following are the different setup/configuration modes for the different TNCs. 3.1.1. TNC-1 or Heath HD-4040 The firmware for the TNC-1 is available in either a downloadable version or a standalone version. I will describe only the standalone version here. Locate the ROM labled E000 and remove it. Insert the KISS PROM in its place making sure that you orient the prom in the same direction (failure to do so will result in smoked PROM). Connect your TNC-1 to your computer using an RS-232 cable. A cable that passes the signals from pins 2, 3, and 7 is sufficient. Since the TNC-1 has no switches for setting the baud rate to the computer the firmware has been "hardwired" to 4800 baud. See the documentation that comes - 9 - with the TNC-1 version of KISS for instructions on how to patch the .HEX file for other baudrates. 3.1.2. TNC-2 and Clones First step is to prepare your TNC-2 for use with TCP/IP. The standard firmware for the TNC-2 is not very computer friendly and, as such, is not very useful when it comes time to make your computer speak with other computers. To that end Mike Chepponis, K3MC, wrote the KISS (Keep It Simple Stupid) TNC code. There are two ROM versions for the TNC-2. The first is contained in a type 2764 or 27C64 EPROM. This version contains the KISS code in it. The second version is contained in a type 27256 or 27C256 EPROM and contains both the standard TAPR 1.1.3 TNC code and a loader that will permit you to download the KISS code into the TNC. Check the EPROM you have received and determine which type you have. If you are burning your own EPROMs you probably do not need these instructions. Open up your TNC and locate the ROM. It is in the socket labled "U23." Using a small nail file or screwdriver gently pry up the existing EPROM. Carefully press the new EPROM into place being sure that the orientation is the same. If you are installing the 2764 type of EPROM you will need to make a small modification to the TNC. There is a location on the board just above the first RAM socket labled JMP-6. Turn the board over and cut the trace joining the two pads. Solder a two-pin jumper header in place. When using a type 2764 the jumper at JMP-6 should be removed and installed when a type 27256 EPROM is being used. That should complete the hardware part of the installa- tion. As an alternative you may choose to burn the KISS code into a 27256 and not bother with jumpers. Attach your TNC to your PC using an RS-232C cable. You can use the same cable that you were using to connect your PC to your TNC. If you are doing this for the first time and are not sure about your cabling, a cable with just pins 2, 3, and 7 passed through is sufficient. Some PCs like to see the signals Clear To Send (CTS, pin 5), Data Set Ready (DSR, pin 6), and Data Carrier Detect (DCD, pin 8) asserted. You can set this up by jumpering pin 4 to 5, and pin 20 to pins 6 and 8 at the female DB-25 connector that goes to the PC. Now to verify that the TNC still works. Apply power to the TNC and turn it on. The STA, CON, and PWR LEDs should come on and the STA and CON lights should go out again about 1 second later. If you have the type 2764 EPROM with the KISS code in it one or both of the STA and CON LEDs will begin to flash. If the CON LED flashes you have 8Kb of RAM in the TNC. If the STA LED flashes you have 16Kb of RAM. If both LEDs flash you have 32 Kb of RAM. The flashing of the LEDs verifies the proper operation of the TNC. If you got the combined loader and TAPR vers 2000 ion EPROM, checkout is a slightly different process. You can test your TNC-2 using two methods. The first method is to connect your TNC to a terminal program and send the character 'h' or 'H' to the TNC. The result should be the standard TNC startup message. Exit from the 1.1.3 mode of operation by issuing the reset command to the TNC. The second method involves downloading the KISS code to the TNC. Use the mode command to set the baud rate of the comm port to the proper value, e.g. it matches the DIP switch setting on the back of the TNC, and copy the file tnc2kiss.hex to the appropriate comm port. The following command sequence - 10 - will serve to download the KISS code to the TNC: mode com1:4800 copy tnc2kiss.hex com1: If the download was successful (it takes about one minute) the STA and/or CON LEDs will begin flashing as described in the previous paragraph. If the down- load is not successful check the cable from computer to TNC, check the baud rate on the TNC, and check to ensure that the computer is indeed sending data to the TNC. Once this is done the TNC is ready to use with the NET program. NOTE: running KISS causes the stored parameters in the TNC, i.e. MYCALL, NEWMODE, TXDELAY, etc., to be destroyed. Every time you shift from KISS to TAPR modes you MUST reset the parameters. 3.1.3. AEA PK-232, PK-87, or new Heath TNC (PK-232 clone) If you have one of these boxes, congratulations! You do not have to change PROMS! KISS is already installed as a standard feature if you have a recent release of the firmware, 4-MAR-87 or later for the PK-232, or 21-JAN-87 or later for the PK-87, you have KISS in your TNC already. To make it work first ensure that your computer can communicate with the TNC in standard packet mode. This will ensure that the computer, TNC, cabling, and radio are all operating properly. [Please note that one of the commands "PACKET" is not valid on the PK-87 and will only elict a "Huh?" response. Please note that comments have been added to the commands. Do not type the information following the double dash or type the double dash itself.] Here is the sequence of commands that will turn on the KISS mode for the AEA products: AWLEN 8 -- ensure it can speak 8 bit data PARITY 0 -- no parity RESTART -- warm reset; make the previous commands take effect PACKET -- PK-232 or Heath only TONE 3 -- PK-87 only START 0 -- start, stop, xon, xoff, xflow to disable software STOP 0 flow cont XON 0 XOFF 0 XFLOW off CONMODE trans -- pass through all characters HPOLL off -- disable host polling KISS on -- enable KISS version of host mode RAWHDLC on -- turn off AX25L2 (the protocol is now handled by the PC) PPERSIST on -- turn off DWAIT and enable p-persistence HOST on -- start KISS running The PK-87 or the PK-232 will remain in the KISS mode until you send a break (~200ms of spacing) or until you send the command character three times (^C ^C - 11 - ^C) in quick succession. Beware! Some terminal emulators (like YAPP) will send a break signal when you exit from them. That will undo your work and cause all manner of confusion. The terminal program PROCOMM seems to work just fine. The TNC may also be switched back to ordinary AX.25 mode by issu- ing the following command from within NET.EXE: param ax0 255 3.1.4. Kantronics Kantronics has recently begun to offer KISS on their products. It is the sim- plest of the commercial implementations of KISS to configure and use. First setup and operate your KAM, KPC-II, or KPC-4 for standard packet opera- tion. This will ensure that the computer, TNC, cabling, and radio are operat- ing properly. Use your terminal program to send the following commands: ABAUD 4800 -- set the baudrate to whatever you will be using when net is running (set by the attach command) DWAIT 0 -- disable DWAIT PERSIST 50 -- enable persistence and set it to about 20% SLOTTIME 16 -- set the slot time to 160 ms KISS ON -- Enable KISS mode at the next reset PERM -- make the above command permanent so that KISS will be entered whenever the TNC is powered up RESET -- start KISS If you wish to have the the TNC revert back to ordinary AX.25 mode of opera- tion you should omit the PERM command from the above sequence. That way the TNC will revert back to ordinary AX.25 mode when the power is removed and restored to the TNC. The TNC may be switched back to ordinary AX.25 mode by issuing the command: param ax0 255 This command will work even if the PERM command has been used to make KISS the default mode of operation. 3.2. Installation of NET.EXE on an IBM PC or Clone Create a directory called EXE and set that as the default directory. Use PKXARC to extract the files from EXE.ARC into the new directory. Should you not have PKXARC already, run the program PKX35A35.EXE provided with the dis- tribution. This program will create the extraction utility and its documenta- tion. There are two programs that make up the network software: NET.EXE (the net- working code) and BM.EXE (the mail program). Copy these programs from the EXE directory to the place on your hard disk where you keep command programs. If you are running on a floppy based system you should create a bootable floppy and copy these programs to the floppy. - 12 - Test to make sure that everything is there by executing the programs. Type the command "net" and, if the installation of the network code was successful, the message "KA9Q internet protocol package" and the prompt "net>" will appear on the screen. This means that the network code is running and awaiting com- mands. Exit from the net code with the command "exit." Now run the command "bm." The screen should display the message "Bdale's Messy-DOS Mailer" and the prompt "Brian"> will appear (this prompt or something like it is a function of the content of the bm.rc configuration file). If all this has occurred, all is well so far. If you do not get this response from bm, do not be concerned. Try again after you have configured bm in the following steps. 3.2.1. Installing the Mail Directories used by BM First step is to configure the mailer (BM). To make BM work properly you must create the following directories on your disk: \spool \spool\mail \spool\mqueue Copy the file SEQUENCE.SEQ to the \spool\mqueue directory. Copy the files HOSTS.NET and BM.RC to the root directory of the default drive used when net is running. If you are on a floppy based system you need to put BM.RC with NET.EXE, BM.EXE, AUTOEXEC.NET, HOSTS.NET, and AUTOEXEC.BAT in the root (\) directory (more on AUTOEXEC.NET later). 3.2.2. HOSTS.NET You will need to edit the file HOSTS.NET to know about all the systems with which you will exchange mail. This is how net will translate the name into the IP address. Here is an example of some of the entries I have in my machine for other local TCP/IP stations: 44.96.0.2 WB2SEF 44.96.0.16 N8FJB 44.96.0.17 KA3LYQ Roel All this does is translate the symbolic name to the IP address, e.g. WB2SEF gets translated to 44.96.0.2 so that IP can route it to the proper network node. This saves you from having to remember lots of numbers. You may note that the last entry has two a 2000 liases, either of which may be used to specify the IP address 44.96.0.17. There is essentially no limit to the number of aliases that may be listed for a single IP address. Just be sure that they are all on one line. 3.2.3. BM.RC Next edit the file BM.RC. This file lets the mail system know about local host name, user name, and editor name. Here are some example entries: - 13 - host wb6rqn.ampr user brian edit emacs The edit entry should contain the name of your favorite editor, such as edlin (edlin is not your favorite editor?). This editor will be used to construct a mail message when you invoke that function of bm. You may use any DOS compa- tible editor just so long as it has the capability to prepare ascii files (be careful if you specify a word processor -- some word processors embed special characters in the file). Later on you can read the documents BM.DOC and SMTP.DOC to get more informa- tion. You at least have enough info to get your mailer running now. 3.2.4. FTPUSERS Now you need to possibly modify the \FTPUSERS file to permit users to send and receive files from your system. The FTPUSERS file contains the information about users in the following format: user password \directory permission-code The 'user' entry is the user's name, 'password' is the password for that user, '\directory' is the directory to which the user will have access (all of the subdirectories too), and permission-code is a number between 0 and 7 that defines what the user may do. The permission-code is a bit-map where the three least significant bits each have a specific meaning. Here is a table: 1 - read and directory access 2 - create access 4 - overwrite and delete access The protection bits are added together to create the permission-code. For example 3 (1+2) permit the user to read files and create new files but not overwrite or delete and existing file. A permission-code of 7 (1+2+4) would permit full access. Here are some examples: guest * \public 3 brian xyzzy \ 7 In these examples guest may log in with any password and may copy files or create new files in the directory \public while user brian must log in with password xyzzy but will be granted full access, e.g. read, write, overwrite, and delete, to all files in the system. If you are running in a radio-based environment I would not give out the latter user/password combination because it will give anyone access to your - 14 - entire disk. Also remember that the user/password combination are broadcast in-the-clear for anyone to read (if they have trace turned on). It is wise to segregate your radio-link users in a separate directory tree and not permit delete or overwrite access. That should prevent malicious mischief. 3.2.5. Configuring NET and the AUTOEXEC.NET file: Now you need to configure and run NET. Configuring NET to run may be per- formed manually every time you start up NET.EXE but that gets old pretty fast. There are usually many commands that must be typed the same way every time net is started. Fortunately Phil thought of this and provided the AUTOEXEC.NET file. The intention here is to place all the commands that you always execute in a file to be read and executed by NET.EXE whenever you start up. To this end you will want to edit the file AUTOEXEC.NET prior to running NET.EXE. Just use a text editor to enter the commands into the file AUTOEXEC.NET as you would type them at the "net>" prompt. 3.2.5.1. Setting the IP address: When NET.EXE first starts up you need to tell it about many things, i.e what comm ports you have, what your IP address is, what your host name is, what other systems you will communicate with, what services you wish to provide, etc. The first thing to do is to tell net who we are with the ipaddr, host- name, and mycall commands. Enter your ip address in dotted decimal notation or give the symbolic name from your HOSTS.NET file. Here is an example: ip address [44.96.0.1] The selection of an address is very important. If you are going to be part of a network you must have a unique address. Talk to the person in your area who is responsible for coordinating addresses. If you are not a part of the Internet and are just using this with your own computers, pick any unique address that suits you. NOTE: Throughout this document names and IP addresses are inter- changable. Net differentiates between the two by requiring you to enclose IP addresses in square brackets []. 3.2.5.2. Hostname: The hostname command is used to set the name of your system. This is displayed when someone initiates an FTP session with your system. Again here is an example: hostname wb6rqn.ampr This corresponds to my system in my local domain. For the purposes of amateur packet radio your callsign followed by "ampr" (amateur packet radio network) is probably sufficient. - 15 - 3.2.5.3. AX25 Mycall (packet radio only): Since I also run net on the air (amateur packet radio networking) I must specify my amateur call sign with the ax25 mycall command. Again, here is the entry from my AUTOEXEC.NET file: ax25 mycall WB6RQN-0 The callsign is entered in the same form that is used with the standard TAPR TNC software, e.g. the callsign is followed by the SSID field. If you are going to run TCP/IP on the air using the ax25 driver (described below with the attach command) the ax25 mycall entry MUST preceed the first attach command that uses the ax25 driver. Otherwise there is no required order for these commands. 3.2.5.4. Attach command The attach command tells net about your comm ports and in what mode the ports will operate. Currently four types of comm hardware are supported: standard PC async comm adaptors, the HAPN TNC board for the PC, the Eagle RS-232/2 card, and the 3Com Ethernet controller. Each of these devices has its own version of the attach command. Here is the attach command for an async adap- tor card acting as COM1:. You would use this to attach your pc to a TNC run- ning the KISS code: attach asy 0x3f8 4 ax25 ax0 1024 256 4800 This means attach an asynchronous adapter whose port address is 3F8 hex using interrupt line 4 (both standard for com1:), as an ax25 device (KISS TNC), using a buffer size of 1024 and a maximum transmission unit (the largest packet you are allowed to send) of 256 bytes, running at 4800 baud. The media name for this device will be ax0, a name that will be used in the route, con- nect, and param commands to refer to this comm port. This is probably a pretty good place to start. If you also wish to use COM2 instead of or in addition to COM1 you would add the line: attach asy 0x2f8 3 ax25 ax1 1024 256 4800 If you are instead going to use COM2 to connect with another PC using a hardwired connection (some of us do have multiple PC's) you might want to use COM2: to connect to the other PC. We would want to use SLIP to do this so the attach command would be: attach asy 0x2f8 3 slip sl0 1024 576 4800 NOTE: IBM-PCs and clones all use I/O port address 0x3f8 and inter- rupt request line 4 for COM1 and port address 0x2f8 and interrupt request line 3 for COM2. There are other comm cards that implement COM3, COM4, etc., but these cards may use non-standard port - 16 - addresses and interrupt request lines for these ports. Check the documentation that came with your comm card if you are trying to use COM3 or higher. 2000 If you have an HAPN TNC card for your PC you will want to enter the following attach command: attach hapn 0x3f8 4 ax25 h0 1024 256 csma This tells net to use an HAPN board with the port address 3F8h and interrupt request line 4. The speed of the board is determined by the board so the software has no control over that function. The last parameter, listed as operation. Recently the Eagle RS-232/2 card has become available at very reasonable prices. This two-channel card generates HDLC frames directly and may be con- nected to a modem for direct packet radio operation without a TNC. Normally it would be connected to a Bell-202-type half-duplex asynchronous modem. The attach command for the Eagle board is almost identical to that of the standard async comm card. Here is an example: attach eagle 0x300 5 ax25 eg0 2048 256 1200 Two items must be as shown in the example: the mode must always be ax25 (not SLIP) and the media name must begin with 'eg' and end with a single digit. The first Eagle card must be called eg0 and the second must be called eg1. The Eagle card is hardwired for a base address of 0x300 and IRQ5. The use of IRQ5 conflicts with the disk controller on the PC/XT (no problem with the PC/AT). If you wish to use the Eagle card with a PC/XT or compatible you will need to locate the trace from pin 3 of the 74LS125 (U12) to B23 (IRQ5) on the edge connector. Cut this trace at the edge connector and reroute it to B4 (IRQ2) on the edge connector. This will eliminate the conflict and allow you to use IRQ2. If you happen to have more than one PC you may wish to connect them using an Ethernet. The net software supports the 3Com 3C500 or 3C501 boards for the PC. The command to attach this board is: attach 3c500 0x300 3 arpa ec0 5 1500 This tells net that there is a 3Com 3C500 board at I/O address 300h using interrupt request line 3 with the media name ec0. Net should reserve five buffers and the largest Ethernet packet may be 1500 bytes long. A word about the selection of the value for the maximum transmission unit. For standard TNCs and radios 256 is probably the largest value you should use. This ensures compatibility with the rest of the AX.25 community and ensures that you are legal if you are operating unattended (part 97 of the FCC regula- tions specifically mentions the AX.25 protocol in permitting unattended - 17 - digital operation above 50 MHz). The smallest value you may use is 64. Per- formance improves with larger values IF you can get them to the other end without errors. I suggest you stick with 256 until you can run some experi- ments of your own. If you have a good transmission path and all the stations and gateways are attended, feel free to use larger values. It will result in improved performance (see the discussion of the mss and window parameters). 3.2.5.5. Param command: If you are using a TNC running the KISS code (you probably are if you are operating amateur packet radio) you will need to set the parameters in the TNC. This is accomplished with the param command. There are five settable parameters in the kiss code. They are: 1. Transmitter keyup delay (TXD). This is how long the TNC will wait after keying the transmitter prior to beginning to send data. The proper value for this parameter is dependent on your configuration. This value is in 10's of milliseconds. Acceptable values range from 0 (0 ms) to FFh (2,550 ms or 2.55 seconds). 2. Persistence (p). This is the probability that the TNC will key your transmitter if a slot is found empty (the channel is free). Acceptable values range from 0 (p = (0+1)/256 = 0.4%) to FFh (p = 255+1/256 = 100%). The default value is 3Fh (25%). The optimum value is somewhere close to 1/n where n is the number of users on the channel. 3. Slot time (ts). This is how long that the TNC will wait between samples of the channel. Acceptable values range from 0 (0 ms) to FFh (2,550 ms or 2.55 seconds). 4. Tail timer (tt). This is how long the TNC will keep the transmitter keyed after the last character has been transferred to the HDLC con- troller. This has become an outdated command since most of the TNCs now set this value automatically based on data rate. 5. Full Duplex. A zero value (the defalult value) means operate the TNC in half-duplex CSMA mode (listen before you transmit). A non-zero value means transmit whenever there is data to send. Let us assume that on the channel associated with ax0 that I have a radio that requires a transmit keyup delay of 200 ms, I want persistence to be 20% (p=0.2), and I want the slot time to be 160 ms. These are the values that we use in the DC area and make us "good neighbors" who do not "hog" the channel. I would enter the following commands: param ax0 1 14 param ax0 2 33 param ax0 3 10 Note that the parameters are always specified as hexadecimal values. Do not make the mistake of typing 100 thinking that you are entering the value one hundred. The command processor only looks at the last two digits so the - 18 - result would be to enter a value of 00. NOTE: The 'param' command will be used for issuing other device- dependent commands as the need arises. Right now it is used only for setting the parameters for kiss TNCs and the speed of SLIP and AX25 links. Other versions of the 'param' command will be added as the need arises. If you are dealing with a SLIP link (you used the entry slip instead of ax25 in the attach command) the param command is used to change the speed (bau- drate) for the line. If you wanted to change the speed of your second slip link to 4800 baud you would enter: param sl1 4800 3.2.5.6. ax25 digipeat command (packet radio only): If you are currently an active digipeater in your area you can also make your system continue to be a digipeater for those poor souls unlucky enough to still be running ordinary AX.25. The command for this is: ax25 digipeat on 3.2.5.7. Mail Gateway: The mail subsystem (SMTP) needs to know where to send mail should the destina- tion be unknown to the sending system. This is handled by the gateway command as follows: smtp gateway wa3pxx - or - smtp gateway [44.96.0.13] Should you try to send mail to a host that is not in your HOSTS.NET file the mailer will route the mail to the system specified in the gateway entry. This presumes that the gateway system is smart enough to figure out to whom the mail is addressed so that the mail can be forwarded. At this time the mailer in NET.EXE is not "smart" enough to act as a mail forwarding node. This field is only here should you be lucky enough to have another computer accessable to you with a smart SMTP mailer or another host that acts as a gateway to another network. Any UNIX 4.2 or 4.3 BSD system has such a mailer. A PC running the WA3PXX BBS gateway also will serve. For packet radio enthusiasts another use for the gateway command is to send mail on to your local BBS gateway station. Bob Gibson, WA3PXX, has con- structed a gateway program that will permit the transfer of mail from the WA7MBL BBS to SMTP and back again. By having your local BBS run DoubleDos with the WA7MBL BBS in one partition and NET in the other you can automati- cally move mail between the two domains. - 19 - 3.2.5.8. Construction of Routing Tables: Now you need to construct the routing table. This table is used by the IP to determine how to forward your packets. Each entr 2000 y consists of two or three parts, the IP address of the destination, the link upon which it is to be for- warded, and the IP address of the next station in line if there can be more than one IP address on the link (used if the mode is ax25 and not used if the mode is slip). Here are three sample entries, one for a station more than one hop away via ax25 to be forwarded by 44.96.0.7, one for station one hop away on ax25, and one for a station on the other side of a slip link: route add [44.96.0.5] ax0 [44.96.0.7] route add [44.96.0.2] ax0 route add [44.96.0.12] sl0 route add n3ja ax0 The first string following the command 'route add' is the destination IP address. The second field, i.e. ax0 or sl0, is the media and must match up with one of your previous attach commands. The last field is the next station in the path if the destination is more than one hop away. This is an optional field and only needs to be used if the media is a broadcast media such as Eth- ernet or AX.25 and the destination is more than one hop away. Note that the address may be specified as either an IP address in dotted decimal notation or it may be a symbolic address from your hosts.net file. If you choose the latter technique you must enter the symbolic address precisely as it was entered in the hosts.net file, e.g. upper and lower case characters in the name are significant. If you are using an Eagle RS-232/2 board your media is named eg0 or eg1. There is still a problem because there are two ports on the board. In order to solve this problem you will need to add the letters 'a' or 'b' to the media name. For instance, if you have a single Eagle card your media names become 'eg0a' and 'eg0b' for the A and B ports of the card respectively. Remember, take the media name from the attach command and append either A or B to the end of the name to select the appropriate port. Here are some examples: route add [44.96.0.22] eg0a route add aj9x eg0b wb3ffv There are two other special types of route entries; the default entry and a cluster entry. Here is a default entry: route add default ax0 [44.96.0.99] This means that if the address does not match any entry in your table, route the packet to 44.96.0.99 via ax0. Hopefully the switch at 44.96.0.99 will be able to forward the packet to its destination. This generally works well if you are merely an end node (a leaf) in the network and all your traffic goes to a single gateway. - 20 - 3.2.5.8.1. Cluster Routing and its Associated Concepts: The other option for routing is cluster routing. It allows you to send blocks of addresses in a certain direction. This is useful if all the users in a given area have some common part to their IP addresses. Here is an explana- tion of cluster routing and addresses in general. The IP address is thirty-two (32) bits long. It is generally represented as four 8-bit numbers, with each number being written in decimal form. For exam- ple, my IP address is 44.96.0.1. This number can be represented as the hexa- decimal value 2C600001 or 00101100011000000000000000000001 in binary. We can break this out as follows: decimal 44 96 0 1 hexadecimal 2C 60 00 01 binary 00101100 01100000 00000000 00000001 Normally when you make an entry in the routing table, all bits of the address are significant, e.g. an exact match is needed for the address to be recog- nized. On the other end there is the default route in which any address matches. Cluster routing falls somewhere between these two extremes. Cluster routing allows you to specify how much of the address is to be considered valid. In order to determine how many bits in the address are valid you enter the address in a special format: route add [44.96.0.64]/26 ax0 This means that only the first 26 bits of the address are to be considered significant. This is a form of wild card for the address. Here is that address in binary to show the mapping: 00101100 01100000 00000000 01?????? The question marks in the above address show the least significant six bits being "wild," or matching any corresponding bits in the address. Here are some examples: 44.96.0.67 00101100 01100000 00000000 01000111 (a match) 44.96.0.89 00101100 01100000 00000000 01011001 (a match) 44.96.0.01 00101100 01100000 00000000 00000001 (no match) This works because the routing process in the net code will, when presented with an address, search for an exactly matching entry. Failing to find that it will then look for an address that matches on the most significant 31 bits, then 30 bits, and so on. If presented with the address 44.96.0.67 IP would, after 6 tries, match the address to the example given above. By judiciously assigning addresses we can make the address aid us in routing - 21 - the packets. The users within a LAN should have something in common in the high order part of the address so that we can use a single entry in the rout- ing table to make things go in the proper direction. Here in the Washington DC area all addresses begin with 44.96.0. This identifies this general area and may be used to provide routing to us. Once the packet arrives in our gen- eral area cluster routing is then used to further route the packets to the appropriate area. In DC and the parts of Maryland immediately surrounding DC the low order byte ranges from 0 to 63. Northern Virginia users get numbers in the range of 64 to 127. The Baltimore users get 128 to 191 while the Har- risburg, PA, users get 192 to 255. The idea being that we can use the top two bits in the low order byte of the address to identify LANs within the address. That way the bits in the high order part of the address will get you into the general area, the next part of the address will get you to the proper LAN, and the least significant bits will get you to the proper host or user. 3.2.5.9. Routing Loops and the Time To Live (TTL) Command: It is quite possible (and likely!) to make errors when setting up routing tables that will cause a routing loop to occur (a routing loop is a circular path that never reaches the intended destination). Imagine what would happen if two stations had their default routing pointing at each other like this: host 1 (44.96.0.1): route add default ax0 [44.96.0.2] host 2 (44.96.0.2); route add default ax0 [44.96.0.1] In this case a packet that got routed using the default route would bounce back and forth between the two stations forever. There is a command that can prevent this from going on forever: the Time-To-Live (ttl) command. Every IP packet has a ttl field in it that is decremented by 1 at every hop. When the ttl field reaches zero and the packet is not at the destination the packet is discarded and an ICMP message explaining the fact is sent to the sending host. Normally net sets the ttl field to 255. If you know that no host is more than 5 hops away you might issue the following command: ip ttl 5 This means that all packets from your host/station are sent with ttl set to an initial value of 5. These packets will now be discarded if they haven't reached their destination after 5 hops. This limits the traffic in the net- work should somebody inadvertantly create a routing loop. 3.2.6. Using Digipeaters and the ARP Add Command (packet radio only): Since there may not be many TCP users in your area you may need to use a digi- peater (or two) to reach the other users in your area. This is now possible by adding entries to the ARP (Address Resolution Protocol) tables. ARP se 2000 rves to map IP addresses into Ethernet or AX25 address, whichever is appropriate to the media in use. ARP normally does its work automatically by directly conversing with the other station but it cannot do that if the other station is reachable only via a digipeater. In that case you must "hard-wire" an ARP table entry with the ARP ADD command. - 22 - Before you can use the ARP ADD command you must know the path to the other station. Let us assume that the station with whom you wish to communicate is WA4OIE (Other Internet Experimenter) whose address is 44.96.0.247, but the only path available is via WB3PID (Poor Inefficient Digipeater). In this case you will use the following ARP ADD command: arp add [44.96.0.247] ax25 wa4oie wb3pid - or - arp add wa4oie ax25 wa4oie wb3pid From this point on packets sent over an AX25 link to address 44.96.0.247 will use the AX25 destination addres of WA4OIE with an intermediate digipeater address of WB3PBD. If you need to use more than one digipeater it is permiss- able. Just place the callsigns of the digipeaters sequentially following the destination AX.25 address. 3.2.7. Window and Maximum Segment Sizes: The next information we want to include is some information used by TCP to determine how much data it can send at one time and how much data may be out- standing before it stops to wait for an ack from the other end. Here are the example values: tcp mss 216 tcp window 648 The parameter mss stands for maximum segment size and represents the largest single segment that TCP will send. Mss should be set as a function of the quality of the link over which you are running. Relatively error-free links should use larger values of mss. If you are running on amateur packet radio and wish to operate unattended you should probably limit this value to 216 (an mss of 216 will cause you to send AX.25 packets that are 256 bytes long. The net program now compares the mss value and the mtu values given in the attach command for the media being used. Since TCP and IP each have a 20 byte header (a total of 40 bytes), an mss of 216 corresponds to an mtu of 256. If you are using mixed mtu's, i.e. 256 for AX.25, 1500 for Ethernet, and 576 for SLIP, set the mss to correspond to the largest mtu you are using and let net adjust the mss downward for the media that are using smaller values for mtu. The 'window' parameter is how many bytes may be outstanding at any one time before you wait for an ack. If you have a pretty good link you can increase the value of mss. If window is larger than mss TCP will run as a sliding win- dow protocol, e.g. continue to send packets while waiting for ACKs on previ- ously sent packets. Since TCP uses selective reject (resend ONLY those seg- ments that were damaged or lost) this is not a very expensive proposition. In any case window should always be a multiple of mss to prevent the transmission of "shortie" packets every once in a while. If you are running on a radio channel at 1200 baud remember that a 1024 byte transmission will take seven seconds, a time that can make you unpopular if you have to share the frequency with AX.25 TNCs that cannot adapt to the high - 23 - channel utilization. In those cases it is probably better to reduce window and/or mss values. The above values will make you fit in reasonably with your other AX.25 neighbors. Remember that the efficiency of large packets and long transmissions are probably not worth having your neighbors so angry that they tie a rope between your coax and the bumper of a pickup truck so that they can non-surgically remove your station from your shack. One last point before we move on; the mss and window values that you set will be the ones that your TCP will ask the OTHER station to use. When the session is initially set up the two TCPs will exchange mss and window values. This permits stations to automatically adjust to the capabilities of the other sta- tion. For this reason it is best to get everyone in your LAN to use the same values. 3.2.8. Starting the Servers: Next you need to decide what services you will provide to other users in the network. You must start the servers or others won't be able to make use of your system for mail or file transfers. You will simply be a switch for other users (in fact, for a switch on a hill that may be just what you want). You will still be able to initiate file transfers or telnet sessions but no one will be able to initiate one with you. Should you fail to start the servers anyone trying to access those services on your machine will just receive a "Closed, (reset)" message. For the sake of consistancy you will probably want to use the start command to enable the following services: start telnet start ftp start smtp start echo start discard Telnet is the terminal-to-host and terminal-to-terminal mode, ftp is the file transfer protocol, smtp is the mail system (simple mail transfer protocol), and echo is the echo server (it just sends back any packets it receives -- good for finding out if a switch is out there and running). The discard server simply throws away anything it receives. The echo and discard servers are generally used for testing a link. 3.3. Running the network program NET.EXE Start the networking program running by issuing the command "net." You should be rewarded by having the "net>" prompt appear on your screen. If you prepared AUTOEXEC.NET as described in the previous section then you don't need to issue any configuration commands. If you have not set up AUTOEXEC.NET you will want to read that section of the manual prior to proceeding with this section. 3.3.1. Operating Modes: Net provides two modes of operation: command and session. In the command mode you are interacting with the command interpreter to permit you to establish sessions, retrieve status information, establish new routing table entries, etc. Please consider the commands you were required to enter in the - 24 - AUTOEXEC.NET file. All of those commands were directed at the command inter- preter. You can tell that the NET.EXE command interpreter is waiting for input because it will present this prompt: net> The session mode is unique to the session with which you wish to communicate. TELNET (terminal-to-host and terminal-to-terminal) and FTP (the File Transfer Protocol) are the two types of sessions with which you may interact and each has its own sets of commands and operating modes. Before you get too carried away with trying things it is probably a good idea to read at least as far as the discussion on multiple sessions. That will explain how to start and use TELNET and FTP as well as how to keep straight all the activity from multiple users. 3.3.2. Running TELNET: TELNET is used to provide terminal mode access to a host computer system but may also be used to have a terminal-to-terminal "chat" with another operator. There are three commands directly associated with the TELNET service: the 'telnet', the 'eol', and the 'echo' commands. ,NH 4 The 'telnet' command: The 'telnet' command is used to establish a TELNET session with a remote TCP socket, usually the TELNET server on a remote host. To establish a TELNET session you would issue the 'telnet' command as follows: telnet wb2sef telnet [44.96.0.2] Both of these commands would establish a TELNET session with the TELNET server at WB2SEF because WB2SEF is defined in HOSTS.NET as having the address 44.96.0.2. Note that we merely specified that we wished to establish a TELNET session and the TELNET client then connected 2000 us with the TELNET server which resides at TCP port address 23. There is an extended syntax for the 'telnet' command that will let you specify the port number at the remote host to which you wish to be connected. Here is an example of the extended syntax: telnet [44.96.0.2] 7 telnet wb2sef 9 In the first example TELNET is being asked to establish a session with port number 7, the echo server, at the host whose address is 44.96.0.2. The second example also is a request to connect to the host whose address is 44.96.0.2 but this time the connection is to be made to port number 9, the discard server. These two ports are regularly used for test purposes, the echo server echoing back everything it receives and the discard server discarding every- thing it receives but returning a proper acknowledgement. Once you have issued the 'telnet' command you will see the message "SYN sent" followed a short time later by the message "Established" (assuming that your - 25 - destination was reachable). At this point you would be in communication with the TELNET server on the other end. If the remote host is a timesharing com- puter (possibly running UNIX) you would very shortly be presented with a login screen. You may consider your keyboard and screen to be directly connected to the remote computer at this point. On the other hand maybe you were attempting to establish a connection with another computer running the net code. In that case you would be in keyboard-to-screen communication with the operator at the remote host (assum- ing that he/she selected the new session as the current session; a subject that will be discussed later). Whatever you type will appear on the other screen and vice-versa. 3.3.2.1. The ECHO Command In addition to the 'telnet' command there are the 'eol' and 'echo' commands. The 'echo' command determines what the TELNET client will do if the remote host offers to echo characters (what we would consider full duplex). Here is the command syntax: echo accept [the default value] echo reject If the remote host is a timesharing computer you probably want it to echo your characters back to you rather than let your local TELNET client echo the char- acters. This permits you to use sophisticated screen-oriented programs without having your local echoing disrupt the screen display. On the other hand you may prefer to reject echoing in the case of a very slow network where having what you type appear on the screen several seconds later could be very annoying. Please note that the setting of this parameter has no effect when entering a TELNET session with another copy of NET since NET always refuses to echo characters. 3.3.2.2. The EOL Command The 'eol' command is also used to adjust the keyboard functionality when remote echoing has been negotiated. It is used to select the appropriate end-of-line character to be sent when the operator presses the or key. Here are examples of the two options: eol standard [the default value] eol unix Should you set 'eol' to 'unix' and remote echoing is negotiated by the two systems, the or key will send an ASCII linefeed character rather than the carriage return character. Normally this will not be needed but some UNIX system demand this. Should the remote host not respond to your key you might want to try this option. To exit back to the command prompt from within a telnet session press the F10 key. The 'net>' prompt will appear. This does not close the TELNET session but merely suspends it. Incoming data addressed to your TELNET session will - 26 - be saved until you re-enter the session (see the discussion of changing ses- sions that follows later). The last item of interest to the TELNET user is how to terminate a TELNET ses- sion. That is accomplished with the 'close' command. To close the session simply press the F10 key to return to the command prompt and enter the 'close' command. You should be rewarded with the sequence of messages: FIN wait 1 FIN wait 2 Time wait [followed by a delay period of about 30 seconds] Closed (Normal) 3.3.3. File Transfer (FTP): The File Transfer Protocol (FTP) permits you to send and receive both text (ASCII) and binary (image) files. The FTP application accepts many commands that will permit you to create files, delete files, change directories, and copy files. This section will guide you through the most used FTP commands. 3.3.3.1. Establishing a Session: To establish an FTP session with a remote host you use the 'ftp' command. To establish an FTP session with WB2SEF I would use one of the following com- mands: ftp wb2sef ftp [44.96.0.2] Both commands do the same thing because of the information contained in my HOSTS.NET file. After issuing one of the above commands you would see the usual 'SYN sent' and 'Established' messages. You would then be greeted by a message from the remote FTP server that looked something like this: 220 wb2sef.ampr (Fri Sep 18 17:57:23 1987) FTP Ready This message tells you that the remote FTP is ready to accept commands from you. FTP gives you no prompt so at this point you must understand that after issuing a command you will be notified of the command's completion but no further prompting for messages will occur. One thing to note is that when FTP sends you a message it will always be prefixed with a three-digit number. This is for the benefit of computer programs that may be driving the FTP sys- tem. The number is for the benefit of the computer and the text is for the benefit of the user. The first thing you will need to do is to log in to the remote host with your user ID and your password. Unless you have been given a specific user ID and password by someone at the remote host you will probably log in with the guest user ID and password. You will send the 'user' and Here is an example: - 27 - user guest 331 Enter password pass xyzzy 230 Logged in This exchange presumes that your user ID is "guest" and that your password is "xyzzy." If the user ID does not require a password you may or may not be prompted for the password. NET always prompts for the password whether it needs it or not. If the remote host is running NET and has in its FTPUSERS file an entry that uses an asterisk (*) for the password, any password will be accepted. If you enter either an invalid user ID or an invalid password the remote FTP will return the following message: 550 Permission denied Simply reenter the 'user' and 'pass' commands with the proper values and you will be logged in. You may also enter new 'user' and 'pass' commands at any time to change your user ID and hence your permissions as far as the remote host is concerned. 3.3.4. Manipulating Directories on the Remote Host: When you log into the remote host you will be set in "your" directory (I put the word your in quotes because many people may be using that directory since many people may be allowed to log in concurrently with the same user ID). You can get a directory listing of files within that directory with the 'dir' com- mand (just like DOS). What you will receive back from the remote host will be a standard DOS directory listing. If you would prefer a short listing, e.g. only the names of the files, you can use the 'ls' command. Both commands will accept wildcards so the following commands are all valid: dir ls *.* dir *.com ls test*.dat After issuing the command you will 2000 see the following sequence of responses from the remote host: 200 Port command okay 150 Opening data connection for LIST \public Your directory listing will be displayed here Get complete, nnnn bytes received 226 File sent OK The end of the "150 Opening data connection ..." response will differ depend- ing on the directory request you made. If you used the 'dir' command you - 28 - would see the word "LIST." If you used the 'ls' command you would see the word "NLST." What followed the "LIST" or "NLST" would be the name of the directory you are listing. In addition to listing directories you can change the directory and query for the current directory. Let us assume that for your user ID (guest) your root directory is \public. Let us also assume that in public you would find the three subdirectories tcp, games, and utils. When you log in your directory is set to \public. Now you issue one of the following commands: cd tcp cd \public\tcp The result would be the same since you were already in directory \public. FTP would then send you the response: 257 "\public\tcp" is current directory You may use the 'cd' command to change directory to any subdirectory below your home directory in the same way that the DOS cd command will also allow you change directories. If you are not sure what directory you are in you may use the 'pwd' (print working directory) command. If we were to issue the command: pwd the remote FTP would then respond: 257 "\public\tcp" is current directory as if you had just changed directories. Now we get down to the meat of the matter: sending and receiving files. Prior to doing a file transfer you need to tell FTP what type of transfer to use. You have two choices: ASCII (text files) or Image (binary files). To select what type of transfer to do you use the type i type a The former will set all subsequent transfers to image mode for sending binary files. The latter will set all subsequent transfers to ASCII mode for sending or receiving text files. If you use the 'type' command by itself like: type FTP will respond with either the word "Image" or "Ascii," whichever is - 29 - appropriate. If you do not specify a type of transfer FTP will use the default value "ASCII." Files transferred with type set to ASCII will have their newline sequence translated to that expected by the remote host. Files transferred with type set to image will have no translation performed at all. All bytes in the file will be transferred with no changes whatsoever. Once you select the type of transfer you desire you may then send or receive files. The 'put' and 'get' commands are used to send and receive files respectively. Let us assume that I have a file on my system in my current directory called "foo" and I want to transfer it to the remote host and have it placed in my current directory there. To do this I would use the following command: put foo FTP would then transfer file "foo" from the local to the remote system. You would know the status of the transfer from the following sequence of messages: 200 Port command okay 150 Opening data connection for STOR foo Put complete, nnn bytes sent 226 File received OK Now let us fetch file "bar" from the remote system. Here is your command the the responses from FTP: get bar 200 Port command okay 150 Opening data connection for RETR bar Get complete, nnn bytes received 226 File sent OK Now it may not be convenient to have the file retain its filename when it is copied. Perhaps there is already a file with the same name at the destination and you do not wish to, or may not be permitted to, overwrite the file. In that case you would add the destination filename to the get or the put command as follows: put foo bar get \public\tcp\herfile herfile In the first example the local file "foo" would be copied to file "bar" on the remote system. In the second example the file "\public\tcp\herfile" would be copied to "herfile" on the remote system. The reason for doing it this way in the second example is to avoid having FTP try to create the file "\public\tcp\herfile" on the remote end. Perhaps there is no directory "\pub- lic" or "\public\tcp" or perhaps you are in an FTP session with a system that has completely different file naming conventions (remember that you may be - 30 - communicating with systems other than PC's). It is also possible to get a file and type it to your CRT directly. If you want to get the file to your screen use "con" as the name of the destinaion file. Here is an example that will fetch file "foo" and send it to the CRT: get foo con You may at some point want to terminate a transfer that is currently in pro- gress. The 'abort' command is used for this. There are no parameters on the abort command. Just type 'abort' and the current transfer will be aborted. The last command of interest to FTP users is the dele command. The dele com- mand is used to delete a file on the remote system. Here is an example that will delete the file foo on the remote system: dele foo Remember that in order to use the dele command you must have delete and overwrite permission on the remote system. When done using FTP use the command 'quit.' 'Quit' will get you the following message sequence: 221 Goodbye! Close wait Last ACK Closed (Normal) All of this indicates that FTP has properly terminated the session and returned you to the command interpreter. 3.3.5. Multiple Sessions: One of the many advantages of NET is that it permits you to establish several sessions concurrently. For instance, you could establish an FTP session with a host and then switch back to the command interpreter so that you could start another session. The nice thing about this is that it in no way interferes with any sessions that are already running. Your FTP session continues to transfer data even while you enter into a TELNET session with the same or a different host. Any screen output that arrives for a session that is not the currently selected session will be held until you again select that session. This prevents you from losing any output while you interact with another ses- sion or with the command interpreter. As mentioned, in order to start a new session (or issue any other type of com- mand for that matter) you must be interacting with the command interpreter. To get to the command prompt you need only press F10. Once at the command prompt you can examine or select a new session using the 'session' command (abrievated 'se'). - 31 - The session command when used by itself will give you a list of all the currently open session. Here are two examples: session se The result will be a display similar to the following: # &CB Type State Remote socket 0 c7a8 Telnet Established w3fws:23 *1 c434 FTP Established 44.96.0.13:21 The first field (#) is the session number. The asterisk (*) identifies the current session. TCB is the TCP Control Block associated with this session (TCB is explained in detail as part of the tcpstat command later in this docu- ment). The Type field identifies the session as an FTP, a TELNET, or an AX.25 connected mode (TNC) session. The state field indicates the state of the "connection" as far as this session is c 2000 oncerned. A value of SYN Sent indi- cates that the "connection" is in the process of being constructed. A value of Established indicates that the "connection" and therefore the session is open and ready to transfer information. Values of FIN Wait 1, FIN Wait 2, or Time Wait indicate that the connection is being closed. The last field, Remote Socket, identifies the host and port with whom the session was ini- tiated. Once you start a session it becomes your current session unless you close it or switch to another session. To get back to a session from the 'net>' prompt all you need to do is press the or key. If you happened to close the current session there will be no current session. In that case pressing or will have no effect. You will need to explicitly select a new session with the session command. If you follow the session command with a number, the session command will make the session whose number was specified, the current session and then turn con- trol of the keyboard and screen over to that session. Here are two examples: session 0 se 0 Both of these examples change the current session to session 0. At that point you will be interacting with the desired session. As mentioned in the section on the 'telnet' command you close a session with the close command. If the session you wish to close is not the current ses- sion you need to issue the command 'close n' where n is the number of the ses- sion you wish to close. Last of all you may need to abort a session or an open socket. This may occur when you have a session with another host and that host goes away for whatever reason (power failure, hardware failure, link failure, etc.). In that case you must resort to the 'reset' command. The without having to go through the - 32 - normal closing sequence. The command format is the command 'reset' followed by a TCB number. Here are two examples: tcp reset c7a8 The first example would force TCP to close the socket associated with the ses- sion with 44.96.0.13 and hence close that session. It would give no indica- tion to the other end that the socket had been closed. The only indication that the other end would receive would be to receive a reset instead of an ACK packet the next time the remote end sent a packet of data. 3.3.6. Status Monitoring and Other Commands: There are quite a few commands in NET.EXE. Many of them were explained in conjunction with the installation instructions and, in fact, have little use beyond initialization. Commands in this catagory include: ipaddr-----setting your IP address mycall-----setting your AX.25 link address ttl--------initial time-to-live field for IP packets attach-----starting a driver for a particular hardware device mss--------setting the maximum size for a TCP segment (packet) window-----setting the maximum number of un-acked bytes digipeat---enable/disable AX.25 digipeating hostname---set the name for your system (used by FTP) On the other hand there are quite a few commands that you will be using exten- sively. Let's start by covering the status commands. 3.3.6.1. Getting Status Information: 3.3.6.1.1. ip status The first of the status commands is 'ip status' and may be abbrieviated 'ips'. This returns information about the status of IP packets that have passed through your system: e.g. originated, received, or passed through (switched). The format for the ip status response looks like this: total 973 runt 0 len err 0 vers err 0 chksum err 5 badproto 0 The 'total' field (973 in this case) identifies the number of IP datagrams that have passed through your system. The next field, 'runt', identifies the number of packets that were below minimum acceptable size. 'Len err' identi- fies the number of packets with length errors. 'Vers err' identifies packets that came from a system running a version of IP that is incompatible with the one that you are running (unlikely to occur unless the Internet adopts a new standard for IP). 'Chksum err' is the number of packets that arrived with a checksum error on the IP header (these packets will be discarded because the system has no way of knowing if any of the information is valid). 'Badproto' identifies the number of packets that arrived with the protocol identifier set to an upper layer protocol (ULP) that is not either TCP or UDP (the only two - 33 - ULP's that are currently supported in NET.EXE). Of all these possible errors you are likely to see only the runt, len err, and chksum err fields increment. Version and bad protocol errors can only occur if you are communicating with a system that supports a different version or a different set of ULP's. This is unlikely to happen. 3.3.6.1.2. tcp status Another often used command is the tcp status command. tcp status returns a great deal of information on the current status of your TCP "connections." Upon entering the command 'tcp status' (abrieviated 't s') the system will print a General status on the TCP activity and an abrieviated display on the status of each TCP session. The top line looks like this: Conout 5 Conin 17 Reset out 2 Runt 0 Checksum err 1 bdcsts 0 at your system while 'conin' is the number of incoming "connections" that have been made with your system. 'Reset out' is the number of resets that were sent to remote systems (this would happen if a remote system attempted to send data to a socket that had been closed). The 'Runt' field is the number of undersized packets that were received. The 'Checksum err' field is the number of TCP segments that were discarded because the segment failed the TCP check- sum check (IP checksums only the packet header while TCP applies a checksum test to the entire TCP segment including header). The last field indicates the number of broadcast messages that have been received. Following the header line a table is presented, one line per socket. The headings appear as follows: &TCB Rcv-Q Snd-Q Local Socket Remote Socket State f784 17 0 44.96.0.1:1001 44.96.0.2:23 Established eb30 0 0 44.96.0.1:23 0.0.0.0:0 Listen (server) In the above example there are two open sockets. The first, associated with the TCP Control Block (TCB) at address f784, is a TELNET (terminal-to-terminal or terminal-to-host) session with the system whose address is 44.96.0.2. The second socket, described by the TCB at location eb30, is a passive open that exists to accept incoming TELNET connections. Now for a more comprehensive description of the fields. The TCB is the TCP control block. The number, in hex, is the address of the TCB in memory and serves to identify a particular open socket. Rcv-Q is the number of octets (8-bit things that we normally call bytes) that have been received and are waiting to be processed (this is one way to tell if you have received information from another station if you are involved in more than one TELNET or FTP session). The next two fields, Local Socket and Remote Socket, make up the identifica- tion of the connection as far as TCP is concerned. The first part of a socket number is the IP address. The second part of the socket number, the part - 34 - following the colon, is the port number. There are many "standard" port numbers in use. Here are some of the more common: Port Application 7 Echo server 9 Discard server 20 FTP server data port 21 FTP server command port 23 TELNET server 25 SMTP server You may see other 2000 port numbers used such as 1001, 1002, etc. These are tem- porary ports that are used to form a unique connection (TCP identifies a con- nection by combining the remote and local socket address in order to guarantee uniqueness). Since no two systems have the same network address the combination of local socket (address + port) and remote socket forms a unique combination. This is how the TCP on both ends of a "connection" identifies that connection. It is possible to get even more information about a specific socket by adding the TCB address to the end of the tcp status command like this: tcbstat f784 This will return the detailed TCP status information about the socket that is described by the TCB at address f784 (you get this address from the tcp status command without a parameter). Here is the sample format: Local: 44.96.0.1:1001 Remote: 44.96.0.2:23 State: Established Init Seq Unack Next WL1 WL2 Wind MSS Queue Total Send: 328b740 328b741 328b741 dffde2e1 328b741 864 216 0 0 Recv: dffde2e0 dffde4e1 1024 0 512 Retry 0 Timer stopped Smoothed round trip time 5500 ms The 'Init Seq', 'Unack', 'Next', 'WL1', and 'WL2' fields have to do with the sliding window nature of TCP. Continuous monitoring of these fields can give you a good idea of the performance of the network in terms of the number of packets lost. The 'Wind' field is the number of bytes that the channel can appropriate ACK can make the window open up (not all ACKs will make the window open because TCP permits receipt of segments out of order). Should the window close completely the sending station will then wait for an ACK so that it may begin sending again. NOTE: A good understanding of sliding window protocols is required to make use of the information presented in these particular fields and a complete explanation is beyond the scope of this document. See RFC-793 or MIL-1778 for more details on the specific sliding window algorithms used in TCP. - 35 - The 'MSS' field displays the maximum segment size; the maximum number of bytes that may be sent as a single TCP segment (packet). Both the maximum window size and MSS are "negotiated" by the TCPs running in the two communicating system. Essentially this means that the two ends "agree" on the best values to use for these parameters. When you set a value for window size and a value for MSS in your machine, those values are communi- cated to the remote end when a socket is opened. That allows the remote end to know how much information you are prepared to accept and to prevent the remote end from sending you too much information. Remember, the values for window and MSS that you set on your system will be the values that the other station will use when sending to you. Also remember that the two ends may set different values and still work effectively. As an aside, you are permitted to change the value of MSS or WINDOW while the net program is running. On the other hand, changing the value of MSS or WIN- DOW after a socket has been opened will have no effect on any currently open sockets. Open sockets will continue to use the value for MSS that they nego- tiated when the socket was opened. The changed values will be used when TCP opens a new socket. The Queue field indicates how many bytes of data are waiting at a particular socket. In the case of the send queue this field indicates the number of bytes transmitted but not yet acknowledged. During SMTP and FTP sessions it is not unusual to see this value equal to the window size. In the case of the receive queue the value indicates the number of bytes that have been received but have not been "picked-up" by the application. The Total field indicates the number of bytes that have been received or transmitted on a socket since the socket was opened. This information is very useful during an FTP session because it will tell you the total number of bytes transferred on the file (FTP opens a new data socket for every transfer, closing the socket when the transfer is complete). If you know the size of the file ahead of time you can use this information to determine how much of the file has reached the receiving end -- nice information to know when doing a long file transfer over a slow or unreliable link. The next field is the retry counter. If a segment is not acknowledged within an appropriate period TCP will retransmit that segement because it will assume that the segment was lost somewhere in the network. Each time it retransmits a segment the 'Retry' counter is incremented. TCP never gives up sending data. It does 'back off' and send segments less and less frequently in order to reduce network loading. The next field is the 'Timer' field. It displays the status of the timer for this particular socket. If TCP is waiting for an acknowledgement to an out- standing segment there will be a time displayed in this field. If there are no outstanding segments the word "stopped" will indicate that the timer is not running. The last field, 'round trip time', is a very interesting piece of information. It is the amount of time that TCP has determined that it takes for an outgoing segment to arrive at its destination and for its acknowledgement to return. This value is used to detwrmine the proper setting for the retry timer thus - 36 - allowing TCP to adapt to the changing conditions of the underlying network and to prevent the network from being flooded by unnecessary retransmissions. The tcp status command is probably the most-used command in the net program. Don't be afraid of it, use it! You may not understand all the fields but you will quickly pick up what is important and what you can ignore. Experiment with it so that you understand it better. It is a key to pinpointing network performance problems. 3.3.6.2. udp status The next status command of interest is 'udp status,' used for getting status information about information that has been received for the User Datagram Protocol (UDP) ULP. This command may be abbreviated 'u.' When an application makes use of the UDP transport service it opens a UDP socket. The udp status command will display the status of the transport service and of each of the open sockets. Here is an example of the output of a udp status command: sent 51 rcvd 50 bdcsts 0 cksum err 0 Unknown Socket 9 &UCB Rcv-Q Local Socket ff38 293 44.96.0.1:3 In this example the 'sent' and 'rcvd' fields indicate how many UDP datagrams have been sent and received respectively. The 'bdcsts' field identifies the number of broadcast datagrams that have been received. The 'cksum err' field indicates how many datagrams have been received with errors while the that were addressed to unknown (unopened) sockets. Following the general information is the specific information about all of the currently open sockets. Each open socket is identified by the address of its UDP Control Block (&UCB). Following that is the number of bytes that have been received and placed on the receive queue (Rcv-Q). Last comes the actual socket identifier consisting of the IP address concatenated with the port number. 3.3.7. AX.25 connected mode operation: In addition to the TCP/IP mode of operation this new version of NET.EXE now supports fully connected AX.25 (TNC-to-TNC) operation for talking to BBS'es and your buddies without TCP/IP. When NET.EXE is running you are free to establish both TCP and AX.25 sessions. When you make an AX.25 connection it will be treated like a TELNET session. You can use the session command to switch between sessions at will. This prevents the output from one AX.25 se 2000 s- sion from interfering with other sessions. To make a connection you use the connect command which is very similar to the TNC's connect command with the exception of the addition of a channel identifier. Here are some examples: connect ax1 wa3pxx connect ax2 n4qq k3af-10 The first command starts a connection to wa3pxx directly over the channel - 37 - labled ax1 (see the attach command). The second example establishes a connec- tion to n4qq via the k3af-10 digipeater on channel ax2. To disconnect you use either the disconnect command or the close command. The other commands for AX.25 are very familiar to a user of a TNC. Here is a list of commands and a brief description of their meanings: ax25 digipeat [on|off] turn digipeating on or off ax25 maxframe [n] set the maximum number of outstanding frames (packets) to n where n is between 1 and 7 inclusive. ax25 mycall [] Set the callsign for AX.25 frames ax25 paclen [n] Set the maximum size of an AX.25 I-field ax25 status Display a status much like tcp status. If you follow it with an ACB address it will display detailed info about a particular connection. ax25 t1 [n] Displays or sets the value of the retransmission timer (FRACK). The value is in seconds. ax25 t2 [n] Displays or sets the value of the ack delay timer (RESPTIME) in seconds. ax25 t3 [n] Displays or sets the value of "keepalive" timer (CHECK) in seconds. ax25 window [n] Displays or sets the number of bytes that may be on the AX.25 receive queue before the host begins sending RNR frames. 3.4. Using connected mode AX.25 for moving IP datagrams: Since connected mode AX.25 is now supported these connections may be used for both host-to-TNC (chatting with your TNC-only equipped buddy or with the BBS) and for connected mode IP channels. With IP you have your choice of "uncon- nected" or "connected" packets. The command that controls this is the mode command. The mode command allows you to select which style of connection will be used on a particular interface. Here are two examples: mode ax0 vc mode ax1 datagram In the first example the interface named ax0 will use "connected" mode AX.25. This can improve the link reliability and hence throughput when the link is somewhat marginal. The second example causes your IP datagrams to be sent in - 38 - UI frames (unproto or beacon packets). This is the mode of choice on reliable links where very few packets are lost. It reduces overhead so packets are transferred more rapidly. 3.5. Tracing and Monitoring: NET.EXE has the most comprehensive and informative tracing features I have seen in any software package for packet radio. The trace function understand AX.25, IP, TCP, and NET/ROM. Tracing is enabled for each interface individually. You have the choice of tracing incoming packets, outgoing packets, or both. The format for the trace command is: trace TIO where is the name of the interface to be traced, T is the trace mode, I is for incoming packets, and O is for outgoing packets. T, I, and O are digits. The following table gives the values for T and their meanings: 0 Trace headers only. Do not display the data. 1 Trace headers and data. Display the data as ASCII, 64 characters to a line. 2 Trace headers and data. Display the data as Hex and ASCII with 16 bytes displayed per line. The values for I and O are either 1 or 0 depending on whether or not you want the respective incoming or outgoing packets traced or not. Here are some examples: trace ax0 010 trace ax1 111 trace ax0 201 In the first example incoming packets on interface ax0 will be traced. Only the headers will be displayed. The second example show both incoming and out- going packets on ax1 being traced. Data in the packets will be displayed as 64 ASCII characters on a line. The last example will display a hex dump of all packets being transmitted on ax0. I recommend using trace liberally. You will learn a lot about packet radio when you can see what is being sent and to whom. The trace display separates the different headers at the different layers. Trace will display the link, network, and transport layer headers separately so you can see their relation- ship. 3.6. Running NET and BM Concurrently In order to get the greatest use out of NET it is important to have it running - 39 - all the time. The problem with that is that DOS is not a multitasking operat- ing system. It is very frustrating to have to start and stop NET every time you want to do something else. There is a solution: DoubleDos. The DoubleDos package from SoftLogic Solutions, Inc, solves this problem nicely. It permits you to split your memory into two partitions and allow each program to operate as if it had its own PC. Phil Karn wrote NET with DoubleDOS in mind and even included the necessary code in NET so that it can effectively reside with other programs without performance penalties to either NET or the other program running in the other partition. This will also allow you to send and receive mail with BM while NET is still running. That way you will not have to exit from NET everytime you want to prepare a mail message or read mail that has arrived. The first step in using NET with DoubleDOS is to install DoubleDOS according to the instructions. Part of installing DoubleDOS is to modify the file \DDCONFIG.SYS for your environment. Many things can be changed in DDCONFIG.SYS but two are important to NET: size and program to load in the bottom partition. When you edit DDCONFIG.SYS you will find a field named 'bottom size' and a field named 'bottom program.' If you want NET to be started automatically when you start DoubleDOS enter the following in DDCONFIG.SYS: bottom program = \NET.EXE DoubleDOS will normally split the available memory in half. This is not the best solution because we know how much memory NET needs and we can then make sure that all of the rest of the available memory is available for the other partition. NET itself needs about 150 Kb of memory. In addition, NET needs COMMAND.COM also loaded in its partition. For this reason you will probably want to allocate about 175 Kb to the bottom partition where NET will run. Let us assume that you want to have both DoubleDOS and NET start when your system boots (just what you want after a power hit). Add the following entry to your AUTOEXEC.BAT file: \doubledos That will cause DoubleDOS to start and DoubleDOS will automatically start NET. 3.7. Installation on a Commodore Amiga < not written yet > 3.8. Installation on an Apple Macintosh < not written yet > 3.9. Installation under Unix < not written yet > - 40 - 4. Operational Reference 4.1. The NET.EXE Program The executable file "net.exe" p 2000 rovides both client and server Internet facili- ties. It implements the various ARPA protocols as both a host and gateway (i.e., it acts as an end-user node as well as an IP packet switch for transit traffic). The keyboard and display is used by the local operator to control both host and gateway level functions, for which a number of commands are pro- vided. 4.1.1. Startup When net.exe is executed without arguments, it attempts to open the file "autoexec.net" in the root directory of the current drive. If it exists, it is read and executed as though its contents were typed on the console as com- mands. This feature is useful for setting the local IP address and host name, initializing the IP routing table, and starting the various Internet services. If net.exe is invoked with an argument, it is taken to be the name of an alternate startup file; it is read instead of autoexec.net. 4.1.2. Console mode The console may be in one of two modes: command mode and converse mode. In command mode, the prompt "net>" is displayed and any of the commands described in the next section may be entered. In converse mode, keyboard input is pro- cessed according to the "current session", which may be either a Telnet, FTP or AX.25 connection. In a telnet or AX.25 session, keyboard input is sent to the remote system and any output from the remote system is displayed on the console. In an FTP session, keyboard input is first examined to see if it is a known local command; if so it is executed locally. If not, it is "passed through" to the remote FTP server. (See the section titled "FTP Subcom- mands"). The keyboard also has "cooked" and "raw" states. In cooked state, input is line-at-a-time; the user may use the line editing characters ^U, ^R and back- space to erase the line, redisplay the line and erase the last character, respectively. Hitting either return or line feed passes the complete line up to the application. In raw mode, each character is immediately passed to the application as it is typed. The keyboard is always in cooked state in command mode. It is also cooked in converse mode on an AX25 or FTP session. In a Tel- net session it depends on whether the remote end has issued (and the local end has accepted) the Telnet "WILL ECHO" option. (See the "echo" command). On the IBM-PC, the user may escape back to command mode by hitting the F10 key. On other systems, the user must enter the "escape" character, which is by default control-] (hex 1d, ASCII GS). (Note that this is distinct from the ASCII character of the same name). The escape character can be changed (see the "escape" command). 4.1.3. Commands This section describes each of the commands recognized while in command mode. Note that certain FTP subcommands, e.g., put, get, dir, etc, are recognized - 41 - only in converse mode with the appropriate FTP session; they are not recog- nized while in command mode. The notation "" denotes a host or gate- way, which may be specified in one of two ways: as a symbolic name listed in the file "\hosts.net", or as a numeric IP address in dotted decimal notation enclosed by brackets, e.g., [44.0.0.1]. When domain server support is added, ARPA-style domain names (e.g., ka9q.nnj.ampr) will also be accepted if a domain server is available on the network to resolve them into IP addresses. 4.1.3.1. Entering a carriage return (empty line) while in command mode puts you in con- verse mode with the current session. If there is no current session, net remains in command mode. 4.1.3.2. ! An alias for the "shell" command. 4.1.3.3. # Commands starting with the hash mark (#) are ignored. This is mainly useful for comments into the autoexec.net file. 4.1.3.4. arp Displays the Address Resolution Protocol table that maps IP addresses to their subnet (link) addresses on subnetworks capable of broadcasting. For each IP address entry the subnet type (e.g., Ethernet, AX.25), subnet address and time to expiration is shown. If the link address is currently unknown, the number of IP datagrams awaiting resolution is also shown. 4.1.3.5. attach