home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware 1 2 the Maxx
/
sw_1.zip
/
sw_1
/
HAM
/
STARTTCP.TXT
< prev
next >
Wrap
Text File
|
1992-01-30
|
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 (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 <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 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 <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 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 <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: AG9V@N8ACV.OH.US.NA
Internet: jra@lawday.daytonOH.ncr.com