Eagle Eye CD-ROM BBS Network/eagle-eye-cdrom-bbs-network.iso/ham_etc/starttcp.txt

Text File | 1992-01-29 | 48KB | 754 lines

            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  [phone]
                    ChowdaNet        [phone]
                    WB3FFV           [phone]
            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,
            [e-mail]. 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 <hostname>.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 <dirname>
            creates a new directory, and rmdir <dirname> removes one.
            Delete <filename> 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 <session number>.  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 <filename> command, and you
            can read in a data file from disk with the upload <filename>
            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 <hostname> at the
            command prompt.  To close a session, press F10 to return to
            command mode and enter close <session number>.  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 <hostname>) 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
            <hostname> 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: <ftp>.  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 <directory> 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
            <local filename> <remote filename> to send a file, or get
            <remote filename> <local filename> 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
            <hostname> 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 @<hostname>
            (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 <user@hostname> 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 [e-mail]
                    # 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 "[e-mail]") while other suggest using the
            callsign instead ("[e-mail]").
            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 <addressee>.  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 <user> rather than <user>@<hostname>.
            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 [e-mail].
                    bill [e-mail].
                    # 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 [e-mail]. [e-mail].
                         [e-mail]. [e-mail].

            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 <msg#> 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 <ipaddr>
                    # your mailbox name at the server
                    pop mailbox <name>
                    # login info
                    pop userdata <name> <password>
                    # how often to check for mail
                    pop timer <seconds>
                    # 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:        [e-mail]
            Internet:    [e-mail]