Getting Started with TCP/IP on Packet Radio by John Ackermann, AG9V Miami Valley FM Association Dayton, Ohio 3 November 1991 Copyright 1991 by John R. Ackermann, Jr. This document may be freely distributed in unaltered form for non-commercial use only, provided this copyright notice is included. Introduction This document is intended to help hams with some experience in packet radio get started with the TCP/IP software written by KA9Q and others. It is not intended to take the place of the software's reference manual, but rather to provide a quick-and-dirty introduction to the capabilities of TCP/IP and the mysteries of installing and using the software. There are several different versions of the KA9Q software floating around. It was originally written for MS-DOS computers, but has been ported to Macintosh, Amiga, and Unix systems. The original program was called NET and its last formal version was issued in April, 1989. If someone talks about 890421.1 NET, that's what they're referring to. Since 1989, work has concentrated on a rewritten program called NOS (for Network Operating System). NOS offers many new features that make using TCP/IP much more effective. However, it is a growing and changing creature, and keeping up with it is difficult. We recommend that you use NOS instead of NET, but we can't tell you precisely where to find the latest version. Your best bet is to check with a local user. If you can't find a copy there, there are several telephone BBS systems that carry the software, but be prepared to find a bewildering array of versions and flavors: N8EMR's Ham BBS (614) 895-2553 ChowdaNet (401) 331-0334 WB3FFV (301) 335-0858 This document is based on the MS-DOS version of NOS, specifically the PA0GRI adaptation of the June 18, 1991 version of NOS as modified and distributed by N1BEE (what a mouthful!) and available as GRINOS from the ChowdaNet BBS. The discussion tries to stay away from features that are specific to that version, but if something we say doesn't seem to make sense with your version of the software, that's probably why. A last note before we plunge in -- we said it before, and we'll say it again: this document barely scratches the surface of NOS. Nearly every command described here has options or parameters that we're ignoring. Our goal is to give you a feel for what TCP/IP does, and to get you on the air with NOS; to get beyond the novice stage you need to look at the reference manual and experiment with the software. TCP/IP and Ham Radio TCP/IP is a set of communication protocols that have become a standard in the computer networking world. It is designed to link different kinds of computer systems together over dissimilar networks. TCP/IP software runs on nearly every kind of computer available, from IBM mainframes to PCs, Macs, and Amigas. The KA9Q software (from now on, we'll call it NOS) is special because it includes the features necessary to run TCP/IP over ham packet radio. The TCP/IP protocols allow different kinds of computers to talk to one another across networks. The services it provides include terminal sessions, file transfer, electronic mail, and data routing services. Computers running TCP/IP (referred to as hosts) can run some or all of these applications simultaneously; it's entirely possible to sit at a PC computer running NOS and carry on a keyboard-to- keyboard chat with one station, while another retrieves a file from your hard disk and you send electronic mail to a third. It's also comforting to know that when you run TCP/IP, you don't give up the ability to carry on normal packet communications. You can use NOS just like a terminal program to establish connections with your local BBS, etc. If you've looked at the size of the NOS documentation, you're probably asking yourself what the benefit is of mastering this fairly complex stuff. Well, NOS has several features that improve on regular packet radio. It has much more sophisticated file transfer and electronic mail capabilities than our present PBBS systems (and it's possible to feed PBBS messages into NOS in a way that makes it much easier to use them). It supports multiple simultaneous connections. It has new and better methods of dealing with slow and congested channels that improve the reliability and throughput of packet traffic. And, since it is directly adapted from the de facto standard system of interconnecting computers, it offers the possibility of sophisticated services far beyond anything available on regular packet radio. For example, in some areas ham TCP/IP users can log into multiuser Unix computer systems and run applications as if they were directly connected to those machines. What is TCP/IP? As mentioned above, TCP/IP is actually a set of protocols for the transfer of data across networks of computers. Two of these protocols underlie most of the others, and they give the set its popular name: TCP Transport Control Protocol, a "reliable stream service" (which is a fancy way of saying it makes sure that all the data sent to a remote host gets there). IP Internet Protocol, which sets the basic rules for formatting packets of data to go out over a network. TCP rides on top of IP. Now you finally know what TCP/IP stands for, there are a few concepts that are critical to understand because they address the basic problem of any communications system -- identifying the parties to the conversation. The first is the IP Address. Since these protocols are used on lots of different kinds of computers, it was necessary to come up with an addressing system that worked with all of them, and that didn't take up a lot of space. The answer was to make addresses used by TCP/IP systems out of a four byte sequence. We usually print these addresses using the numeric value of each byte, separated by a period, such as [44.70.12.34]. This is known as "dotted notation." The square brackets aren't necessary, but they are convenient to set off ip addresses; we'll use them in all our references. The four bytes are of decreasing significance from left to right (the first byte represents the largest network, and the last byte represents an individual system) and can represent networks and subnetworks of computers. We won't go into all the semantics here, but as an example [44.70.12.34] breaks down as: 44. The network assigned to amateur radio TCP/IP. 70. The subnetwork for Ohio. 12. The Dayton/Cincinnati area. 34 a specific system address within that area. The second important concept is the hostname. Obviously, ip addresses aren't very intuitive. English-like hostnames make remembering addresses much easier, and NOS has the ability to translate a hostname into the matching ip address automatically. A host is any computer running TCP/IP; even when you're using services from another computer, your system is still a host. The convention in ham radio TCP/IP is to use your callsign as your hostname. To help reduce confusion, we usually print hostnames in lower case, and callsigns in capital letters -- my hostname is ag9v, and my call is AG9V (though NOS isn't case sensitive and won't care if you don't do it this way). When we talk about a remote host, we're talking about a machine that you're communicating with via TCP/IP. Closely related to the hostname is the domain name. A domain is a group of machines that are logically (though not necessarily physically) connected together. The domain name for the ham radio network is ampr.org. (the trailing period is part of the name). Domain names are like ip addresses; the periods separate parts of the name, with each part representing a different level in the hierarchy. But the domain name is ordered in reverse --its significance is right to left, the opposite of ip addresses. For the ham network, org (short for "organizations") is the "top level domain." ampr is the second level domain, containing all ham TCP/IP hosts. The period at the end of the domain indicates that there is no higher domain level (note that some versions of NOS don't care about the trailing period; the PA0GRI versions do). There could be more than two domains between a host and the top of the domain tree, but in the ham radio network we don't usually add more levels. When you combine a hostname with a domain name, you get something like ag9v.ampr.org. This is called a Fully Qualified Domain Name (FQDN -- knowing this acronym allows you to sound like a real expert). There's a command in NOS called domain suffix that will tell the program to automatically add the domain name to hostnames that you type. If a host has multiple users, we can add the user's login name at the beginning of the address, separated from the FQDN by a "@" character. This combination is commonly known as an Internet address (the Internet is the general term for all the TCP/IP hosts that are interconnected in the commercial, educational, and military domains) and is the address form used for most electronic mail in the real world. For example, if there is a user "jra" at ag9v, jra@ag9v.ampr.org. would be that user's full Internet address. Now that we have those boring basics out of the way, some of the protocols that use TCP/IP to provide real, useful services include: TELNET The terminal emulation program. In "real" networks, telnet lets a user at one host remotely access a remote host, just as if he was on a terminal directly connected to that computer. In NOS, the telnet function usually connects you to a remote host's mailbox, which acts very much like a personal PBBS. The NOS telnet command does allow you to remotely login to a host that supports that function; in some areas Unix computers connected to the ham TCP/IP network provide that service. FTP File Transfer Protocol. A means of transferring both ASCII (text) and binary (program, data, or compressed) files between hosts. SMTP Simple Mail Transfer Protocol. A (mostly) invisible way of moving electronic mail from one host to another. If you create a message on your computer (using the BM program, discussed below), SMTP will attempt to transfer it to the destination computer in the background. POP Post Office Protocol. SMTP is neat, but it's really designed to work with hosts that are available full time. Most ham TCP/IP stations aren't. POP is designed for them; it allows your incoming mail to be stored at a host that acts as a mail server; when you come on the air, your system automatically asks the server to send you your mail. A couple of other protocols are also useful (or at least handy to use as buzzwords): PING Packet InterNet Groper. A diagnostic that sends a packet to a specified host; if the host is accessible to you and on the air, it responds with another packet. PING tells you how long the round trip took. FINGER A way of finding out information about the users at a host. The finger command can simply list all the users at a host, or spit out information (like the "brag tape" of old) about a specific user. ARP Address Resolution Protocol. IP addresses need to be matched with the correct hardware address (in our case, ham callsign) to allow packets to be sent to their destination. ARP does this by sending out a broadcast message when it needs to know the callsign that matches an address. The proper host (if it's on the air) will answer as the "owner" of that address and provide its hardware address. DNS Domain Name Service. Remembering IP addresses isn't easy. NOS can use a file called domain.txt to contain mappings between hostnames and IP addresses, but that means you need to know the hostname and address of any station you want to contact. Alternatively, a remote host may agree to serve as a domain name server that NOS can query when it needs to know the address of a host. Not all areas have a name server available to the ham community, but in those that do, life is a lot easier. Installing NOS Frankly, there's no completely painless way to get NOS running on your computer. NOS is somewhat picky about the directories used for its files, and there are a number of custom parameters that you must set to teach the program about your environment and your network. Those parameters are contained in a configuration file that most versions of NOS call autoexec.net (PA0GRI versions call it autoexec.nos; our references to autoexec.net mean either variety). You should create the following directories on your disk (NOS can work from either a hard disk or a floppy; it's getting big enough, though, that working from a 360K floppy can be tough): /spool (holds NOS' working files) /spool/help (help files for the mbox) /spool/mail (mail messages go here) /spool/mqueue (mail workfiles) /spool/rqueue (incoming mail workfiles) /finger (home for finger info files) /public (file uploads/downloads) Three files need to go in the root directory of your default disk: autoexec.net (the NOS configuration file)) ftpusers (user ftp/mbox access) domain.txt (hostname file) bm.rc (mail program configuration) NOS uses two executable files. These can be installed anywhere on your file path: nos.exe (grinos.exe) (main executable file) bm.exe (mailer program) Once the directories are created and the files copied, you need to edit the autoexec.net file with a text editor to customize it. A sample file is included as Appendix A. Some of the things you'll have to put in the file are: * Your hostname (usually your callsign in lower case): hostname ag9v. * Your IP address. This is assigned by an area coordinator; to find out who your coordinator is, contact a local IPer, or Brian Kantor, WB6CYT, who is the international coordinator for ham IP address assignments: ip address [44.70.12.34]. * Your callsign. This can include an SSID if you want; local customs vary on this: ax25 mycall AG9V. * "attach" commands to tell NOS how to talk to your hardware. These can get quite hairy; Appendix B describes some commonly used versions. A common one, for a TNC on COM 1 at 4800 baud, would be: attach asy 0x3f8 4 ax25 ax0 1024 256 4800. The "ax0" in the middle of the command is the interface name -- you use it to identify this port to NOS when you set up routing commands and the like. You can use any (short) name you'd like, but the convention for COM ports is to use ax0, ax1, etc. * At least one routing command. NOS needs to know where to send packets. A default route that sends all packets out the ax0 interface is: route add default ax0. * If you have a gateway that can route packets outside the local area, include a route like: route add [44.70.13.0]/24 ax0 ag9v. This command would route packets addressed to any host with "44.70.13" as the first three bytes of its address out the ax0 interface to ag9v, which presumably knows how to get these packets to their destination. The "/24" means that the first 24 bits (three bytes) of the address are significant; NOS will ignore the last byte when making routing decisions. * If you have a domain name server, add a command near the beginning of your configuration file identifying its IP address: domain addserver [44.70.12.34]. If you want users to be able to learn about your station with the finger command, you need to create a text file in the /finger directory called .txt. You can use any ASCII text editor to create the file; it should contain basic info about your system. Don't go overboard... a screen full of text is plenty. You can also create additional files with information about specific aspects of your system. For example, I might have a list of the files available for downloading on my system in a finger file called "filelist.txt." A remote host who issues the command finger filelist@ag9v will get that list. You may need to customize other parts of NOS; a review of Appendix A will show you the most common configuration commands. Once NOS is installed and your configuration files set, you need to do one more thing: get your TNC talking to your computer in KISS (Keep It Simple, Stupid) mode. KISS is a special protocol that lets your computer do the work of processing packets; the TNC does only the very low-level packet assembly and disassembly functions. Nearly all TNCs support KISS in one way or another. Typically, you'll need to issue commands to the TNC to set the serial line baud rate to the same speed as you've specified in the attach command, to 8 bit data, and to no parity. Then, issue the KISS command (on a TNC2, kiss on), and the TNC's software reset command. After that, you won't be able to talk to your TNC via the terminal program, but NOS will be able to. (And don't worry, you can easily return the TNC to normal mode if you want to.) Once you've done this, you're set to run NOS. Using NOS To run NOS, first make sure you have your TNC configured for KISS mode and turned on. Then, type nos (or grinos for the PA0GRI version). In a few seconds, you should see a net> prompt. Any error messages that appear first probably indicate a problem with your autoexec.net file. When you see the prompt, NOS is in command mode. When you are communicating with another host, NOS is in converse mode. To get back to command mode from converse mode, press the F10 function key (sometimes called the escape key). All commands typed at the NOS prompt need to be followed by the return key. Typing ? in command mode will display a list of commands. Typing a command name followed by ? will display the valid subcommands. You can't really call it a help system, but it's better than nothing. You can issue several commands from within NOS to deal with files and directories. pwd displays your current working directory, and cd allows you to change directories. dir displays files in the current directory. mkdir creates a new directory, and rmdir removes one. Delete erases a file. You can also "shell out" to DOS from within NOS by entering either an exclamation mark (!) or the command shell. To return to NOS, type exit at the DOS prompt. From command mode, you can start a number of different types of sessions. Each session has its own display screen and you can switch between a session and command mode, or between sessions. The se command displays the active sessions with identifying numbers. To switch to a session, you can type se . From command mode, you can return to the current (most recently displayed) session by entering a carriage return. You can capture incoming data from the current session to a disk file by using the record command, and you can read in a data file from disk with the upload command. The most common NOS session types are probably telnet, its cousin ttylink, ftp, and a regular packet connect (technically called an ax25 session). Telnet is used to "login" to a remote host, ttylink is a kind of telnet specially designed for keyboard-to-keyboard communications, and ftp handles file transfers. The connect command simply lets you do normal packet radio stuff. Establishing an ax25 connect through NOS is just like using the standard TNC commands with a few small differences. First, since NOS can support several interfaces, each with its own hardware, you need to tell NOS which one to use. So, to connect to N8ACV on interface ax0, enter connect ax0 N8ACV. Once you get a Connected message, you'll be able to type to the station at the other end just like you would with normal packet. To disconnect, press F10 to go back to command mode and type disconnect at the prompt. (Just as with a TNC, these commands can be abbreviated; just how few of the letters are necessary will depend on each implementation of NOS and the commands it supports). The other minor difference between the NOS connect command and a regular TNC is that the word via is not used when specifying digipeaters. To connect to N8ACV through N8KZA on interface ax0, you would enter connect ax0 N8ACV N8KZA. The telnet command logs you in to a remote TCP/IP host; depending on the capabilities of that host, you might find yourself chatting directly with the user at the other end, connected to mbox (which acts very much like a sophisticated personal PBBS), or getting a Unix "login:" prompt. To establish a telnet session, enter telnet at the command prompt. To close a session, press F10 to return to command mode and enter close . If there's only one session open, you can just enter close. You can also end the session by issuing the appropriate exit or quit command at the remote host's prompt. Some versions of NOS offer a new type of session that improves on telnet for real-time keyboard-to-keyboard chats. It's called ttylink, and works just like telnet (for example, start a session with ttylink ) except that it connects you directly to the remote host's chat mode, and uses a split-screen format to make things less confusing as you type to each other. You'll get a message like "Telnet session 1 failed: Reset/Refused errno 9" if the remote host doesn't support ttylink. If the operator at the other end isn't available to chat, you'll get a message like "The system is unattended." You'll still be able to type, but there won't be anyone there to reply. You can change the status on your machine by setting the attended command either on or off. You might want to put this command in your autoexec.net file to set your default status. You exit from ttylink just as you would from telnet. And now a note from Miss Manners: you should never simply exit NOS when you have an open session. Doing so can cause great unpleasantness at the remote host. Unless you're in some sort of software or hardware lockup, or you know that the station on the other end has gone away, always close sessions and wait for confirmation before exiting the program. You should also be aware that your system may have started sessions in the background, for example to transfer electronic mail, or someone else may have started a session with your system. You may not even know these sessions are running. Pulling the plug on them would be very impolite. Before exiting NOS, you should first use the se command to make sure there are no current sessions running, and then the tcp status command to see if there are any background connections established. tcp status will show you a long and confusing list of information; the important stuff at the end is the list of sockets (which are services your system can either offer or request on the network). If anything other than Listening appears in the Status column, that means there's at least one remote host communicating with you. Now, on to the file transfer protocol, ftp. You initiate an ftp session just like a telnet one -- by entering ftp at the command prompt. Once the session is established, the remote host will prompt you for a user name and a password. If your hostname and password have been added to the remote host's ftpusers file, you'll have the ability to download and perhaps upload files in the directories permitted you. If you haven't arranged with the remote host for your own account, you can try to login as anonymous or guest; many systems support these user names and grant limited (usually download-only) privileges to them. If you login under one of these accounts, you should enter your hostname as the password; that allows the remote host to keep track of who's been using the system. Once you've logged in, you'll see a new prompt: . This will remind you that you're actually issuing commands to the remote computer. From the ftp> prompt, you can list the files in a directory, change directories, upload files, or download files. To list files, enter dir at the ftp> prompt. You will get a listing that shows subdirectories (if any) and files together with their dates and sizes. To show the current directory name, type pwd. To change directories, issue the cd command. Note that directories are displayed with a forward slash (/) instead of the usual MS-DOS backslash (\). That's because the Unix operating system, which is TCP/IP's natural home, uses forward slashes. If the remote host is running NOS, you can use either character, but some other systems (particularly those running Unix) will recognize only the forward slash. Once you've found a file you want to upload or download, you need to make a decision. ftp can download the file either as an image file, byte for byte, or as an ASCII file, converting the line-end character as necessary to compensate for different operating systems (Unix uses only a linefeed character at the end of lines; MS-DOS uses carriage return/linefeed). Before beginning a file transfer, enter either type i for an image file, or type a for an ASCII file, at the ftp> prompt. What are the consequences choosing the wrong type? Well, transferring a binary file as type a will almost certainly fail. Transferring an ASCII file as type i will work, but you may find that the line-ends are screwed up. ASCII transfers are also quite a bit slower than image, because each line needs to be processed separately. To actually start a file transfer, use the command put to send a file, or get to receive a file. The file name can include a full path if you desire. If you only specify one filename, ftp will assume that both the local and remote hosts will use the same name. This can be dangerous if the remote host uses a different operating system than you do, as it may have filenames that are illegal on your system. If a file transfer goes awry, you can terminate it by going to command mode via F10 and issuing the abort command. To end an ftp session, you can either type quit at the ftp> prompt (the preferred way), or you can close the session from the net> prompt. If you want others to be able to access files on your system, you'll need to set up an ftpusers file in your root directory. Appendix C describes the contents of that file. Another message from Miss Manners: transferring files via ftp is reliable, but can be slooooow, particularly at 1200 baud. Before you start downloading a 250 kilobyte file, consider how busy the channel is, and whether you want to tie things up for (perhaps) several hours by your download. NOS is polite and won't hog the channel, but don't doubt that a large file transfer will slow things down for everyone else. The ping protocol mentioned above is very useful to see if a remote host is on the air. Just enter the command ping at the NOS prompt. If the host is available, you will see a response indicating what the round-trip time was to that host. The time may be many seconds if you're going through gateways, so be patient. The finger protocol lets you see information about a remote host's users and services. Entering finger @ (note the slightly different syntax -- the "@" symbol must immediately precede the remote hostname) will display a list of the users (actually, finger files as described above) at that host. Entering finger will display the text file for that user. Before we move on, a warning. One of the packet BBS programs, msys, includes support for TCP/IP. Unfortunately, the implementation in the current version is not good. If you plan to talk with an msys station, be prepared for lots of strange problems -- and don't believe them when they tell you that you are polluting the channel. Electronic Mail We've saved NOS's electronic mail capabilities for last because they are a bit more involved than some other parts of the program. This is because you use two programs to handle mail: bm to write and read messages, and NOS to send and receive them. First we'll talk about reading and writing messages, and then about using NOS to transport them. bm.exe is a program that reads and writes mail message in the format TCP/IP systems recognize. Contrary to popular belief, "bm" stands for "Bdale's Mailer" in honor of its creator, Bdale Garbee. You can run bm in one of three ways: from the DOS prompt just like any other program, from within NOS by shelling to DOS with ! or shell, or (in grinos) by typing the mail command from the net> prompt. Before using bm, you need to create its configuration file, bm.rc, which must live in the root directory of your disk. There are quite a few commands you can include in bm.rc, but only a few are necessary to make the system work. A workable bm.rc is quite short, so here's an annotated version of one (comments follow the "#" signs): # bm.rc # your hostname host ag9v.ampr.org. # the user name; usually your callsign user ag9v # your full name, for the message "From:" line fullname John Ackermann # if you want to have replies sent to another host, # because, for example, you are using a pop server, # this line specifies where replies should go reply ag9v@ag9v.ampr.org # for faster screen writes on the pc, use direct # video, not bios screen direct # if you want to use an editor different than bm's # built-in one edit ed # put saved messages here; note use of "/" instead # of "\" mbox c:/folder/mbox # save a copy of outbound mail here record c:/folder/outmail # folder for your mail folder c:/folder # maximum number of messages that can be pending maxlet 200 Only the first three of these commands are absolutely necessary to make bm work. There's a bit of controversy in some areas over the proper name to enter for user. Some folks recommend using either your first name, or your initials (for example, my address would be "john@ag9v.ampr.org") while other suggest using the callsign instead ("ag9v@ag9v.ampr.org"). While using the callsign may seem more impersonal, it has major advantages when mail is moving between TCP/IP and the packet BBS system, or when using the pop server; we strongly recommend that you use the callsign@hostname format unless local objection is even stronger. It's important to be consistent within the area, so that everyone knows how to address mail to everyone else. When you start bm, you'll see a prompt such as ag9v> showing the default mailbox (based on the user entry in bm.rc). As in NOS, you enter commands at the prompt, following them with a carriage return. Most bm commands are single letters, optionally followed by a mail addressee, or a message number (or numbers). To send mail, use the command m . The addressee will normally be a user at a remote host; for example, ag9v might send mail to k8gkh@k8gkh. The single biggest problem with bm is remembering to include the hostname -- in other words, sending mail to rather than @. Without the hostname, bm will think the user is on your local system, and the mail will end up being stored in a mailbox under that user's name on your own system. That doesn't work too well. One way to solve that problem, and do some other interesting things, is to create an alias file in your root directory. When you send a message, bm will compare the addressee with the alias file, and if it finds a match will replace the alias with a full address from the file. An alias can point to a list of addresses, so it's possible to define an alias that will send a copy of the message to everyone in your local group. A sample alias file might look like: greg k8gkh@k8gkh.ampr.org. bill n8kza@n8kza.ampr.org. # note that one alias can expand to more than one # address. An alias can extend to additional lines # by indenting subsequent lines with a tab or space. club k8gkh@k8gkh.ampr.org. n8kza@n8kza.ampr.org. n8acv@n8acv.ampr.org. wb8gxb@wb8gxb.ampr.org. Now, if you send mail to "greg," it will automatically be expanded to the full address, and by sending a message to "club," all four users will get a copy. If you use bm's built-in editor to compose messages, remember that it doesn't wrap lines; you have to hit the carriage return at the end of each line. You can list outbound mail with the l command; you can kill an outbound message with the k command (the message number is obtained from the output of the l command). Several commands are used to deal with incoming mail. h displays the headers (summary info) about messages in your mailbox. It is the basic command you should use to check your incoming mail. Each message header displayed will have a number to use with the other message manipulation commands. Commands given without a message number act on the current message (the one displayed with a > by it in the display from the h command; if there's only one message, it is always the current one). The commonly used commands (which may be followed by one or more message numbers if appropriate) are: msg# message number by itself will display that message and set it as the current message. r reply to a message. d delete a message. s save a message; if a file name follows the message number(s), the message(s) will be saved in that file. Otherwise, they'll be saved in the default mbox file. u undelete a message previously marked for deletion. p print a message on the local printer. w save a message to a file without including headers. f forward a message to another recipient. b bounce a message. Like forward, but keeps the original sender information intact (i.e., the message will not appear to have been sent by you). $ update the mailbox. This deletes messages marked for deletion and reads in any new mail that may have arrived since you started bm. There are two commands that exit from bm: x will exit without updating the mailbox. In other words, the same messages will be there the next time you run the program. q updates the mailbox (like $) and then exits. Now, to the mechanics of getting mail into and out of your system. All mail that you create is sent to its destination (or at least to the next stop on the way) by the smtp server in NOS. The smtp timer command (set in autoexec.net) tells smtp how often to scan the /spool/mqueue directory for outgoing mail. When it finds some, it attempts to open an smtp session to the remote host in the address and send the mail there. There's no default for the smtp timer value, so your autoexec.net file should include something like smtp timer 600 (which scans for mail every ten minutes). You can manually force smtp to scan the queue by issuing the smtp kick command from the net> prompt. Incoming mail can arrive at your station when a remote host does this and starts an smtp session with you. But if you don't keep your station up 24 hours a day, the remote host will be trying, and trying, and trying, to connect with you until you finally show up. A far better approach is to use pop -- the Post Office Protocol. If your system runs pop, and a full-time remote host in the area has agreed to be a pop server, NOS will automatically tell the pop server when you come on the air, and the server will respond by sending you all the mail waiting in your mailbox. Running pop requires the remote host acting as a pop server to establish a mailbox and password for you, and you need to add the appropriate commands to your autoexec.net file. Those commands are: # the ip address of the server pop mailhost # your mailbox name at the server pop mailbox # login info pop userdata # how often to check for mail pop timer # do a one-shot mail check now pop kick With these commands, your system will automatically check for mail when you start up, and then periodically while you're on the air. Remember that smtp or pop sessions may be running in the background without your knowing about it. Always check for activity with the tcp status command before pulling the plug! Conclusion This has been a whirlwind tour of TCP/IP. Once you have the software installed, using it is really quite simple. And it opens the door to using packet radio in a whole new way. To learn the subtleties of NOS, you should do two things: read the reference manual for the version you're using, and experiment with the program. Once you know the ins and outs, please share your knowledge with others. The ham radio TCP/IP community is still small, and we need all the Elmers we can get! John Ackermann AG9V TCP/IP: ag9v.ampr.org. [44.70.12.34] PBBS: AG9V@N8ACV.OH.US.NA Internet: jra@lawday.daytonOH.ncr.com