ftp.ncsa.uiuc.edu/ftp.ncsa.uiuc.edu.zip/ftp.ncsa.uiuc.edu/Utilities/mac-tcp.txt

Text File | 2017-03-03 | 67KB | 1,413 lines

MacTCP and related Macintosh software
=====================================
revision 1.1, November 15, 1992

----------------------------------------------------------------
Copyright Eric Behr, Illinois State University, Mathematics
Department

This document can be freely redistributed in whole or in part,
provided that this copyright notice is included intact, and that
no material profit is generated from such a transaction.
----------------------------------------------------------------


With sincere thanks to:
  David N. Blank-Edelman        [e-mail]
  Steve Dorner                  [e-mail]
  Patrick Hoepfner              [e-mail]
  Peter N. Lewis                [e-mail]
  David S. Saunders             [e-mail]
as well as to several contributors to Usenet newsgroups, and to
all those who sent me corrections and suggestions (but I'm the
sole author of all mistakes, omissions and inanities)

Please send all comments and suggestions to [e-mail] or
to [e-mail]. The newest version of these notes
can be obtained by anonymous ftp to spider.math.ilstu.edu, or
138.87.132.21 (file /pub/mac/mac-tcp.txt).


CONTENTS

            PREFACE
         I. General stuff
        II. MacTCP
       III. Applications
        IV. Sources
Appendix A. Peculiarities of Mac file transfers
Appendix B. Elements of Macintosh networking
Appendix C. Dial-in access

PREFACE

   Judging by questions and pleas for help, more and more people
are playing with MacTCP, and many of them are having problems
installing and configuring it.

I've spent many hours installing MacTCP on Macs ranging from the
Plus to a IIci. I also devoted a large part of my free time to
digging up various useful applications for use on the Internet.
Hopefully some of my experiences will be helpful to you.

Please note that I'm not a networking expert. Some of the advice
below simply stems from my paranoia and is not necessarily based
on facts. There are many problems with MacTCP which I don't fully
understand. In addition, please remember that I'm not a technical
writer, and my style may not be to your liking - sorry about that.

Those readers who are new to the field of Macintosh networking
might get something out of Appendix B -- please look at it before
you continue.


I. General stuff

1. Let's begin with a short sermon

   I started using the Internet several years ago, and it has
become an important part of my life - for better or worse. I know
that many people share my feelings about it. For the sake of all
of us, please be considerate! There are lots of things you can
mess up if you don't know what you are doing. Connecting your
computer to the network which spans continents and is used by
millions of people in their work is (or at least should be) a
serious act.

Please follow this simple advice:

o  when in doubt, don't do anything without consulting your
   local knowledgeable system administrator -- chances are that
   if you don't, you will break more than you'll fix;

o  find out how to access the Internet documents (esp. RFC's) and
   read the relevant ones before doing anything tricky;

o  read newsgroups such as comp.sys.mac.comm, comp.sys.mac.system,
   comp.sys.protocols.tcp-ip, comp.protocols.appletalk, especially
   the Frequently Asked Questions collections which are posted in
   most newsgroups from time to time;

o  read the flaming manuals!


2. Where does the Mac fit in?

   The Mac has always been a wonderful network machine. But for
most people "Macintosh networking" means Apple's proprietary
scheme called AppleTalk. The Internet uses a different networking
"language". A major part of it is the protocol known by its
acronym TCP/IP. To access the wonders of the Internet, a computer
must understand TCP/IP.

Even though there are other ways to make the Mac speak TCP/IP, we
will concentrate on the most popular and orthodox one, namely the
"MacTCP driver" from Apple.


3. Various connection methods

   The necessary software is only one part of a network
connection. The other, obviously, is suitable hardware. A
Macintosh can be connected to the outside world in many ways:

o  with a LocalTalk or PhoneNet connector (all Macs)
o  with a modem and suitable software (see Appendix C)
o  with an internal Ethernet card (Mac SE and newer)
o  with an external SCSI Ethernet adapter (all Macs)
o  with an internal TokenRing card (Mac SE and newer)

Until recently MacTCP was not compatible with the last method of
connection listed above. In mid-1992 Apple announced a Token Ring
extension for use with MacTCP 1.1, which does the trick. Even
though we have limited experience with that network driver, most
of the advice below should apply to it.

The problem of providing reliable and convenient dial-in access
would require a separate book. A short note on this subject is
found in Appendix C.

Macs on Ethernet can usually connect to the outside TCP/IP world
without a problem, since that protocol was to some extent created
with Ethernet in mind.

Macs on LocalTalk can communicate with the outside TCP/IP world
only if the LocalTalk is connected to a larger network using an IP
gateway such as FastPath (Shiva), Gatorbox (Cayman Systems),
Multiport Gateway (Webster Computer Corp.), EtherRoute/TCP
(Compatible Systems), or one of other equivalent devices; or if
such a gateway is present elsewhere on your internet, and is
visible to your Mac. None of the software routers like the Apple
Internet Router or Liaison (Inphosphere) currently provides TCP/IP
services, so if that's what you use to connect to an Ethernet, you
must also have a gateway which will translate the IP packets
wrapped in AppleTalk (which your LocalTalk Mac sends) into genuine
IP packets going to the outside world, and vice versa. We briefly
describe some of the details in Appendix B.

Please note that AppleTalk and TCP/IP are two completely different
animals, even though a single Mac can use both at the same time;
configuring AppleTalk functions, such as printing over the network
or AppleShare, will not be discussed here.


II. MacTCP

1. How to get it?

   MacTCP (version 1.1.1 as of this writing) is marketed by APDA
(408 974 4667). Don't expect your local Apple dealer to know much
about it. Current price of a single copy is about $100. A site
license is available, and some institutions may qualify for
discounts. Call APDA. If you already have an old version, you
should have no problems upgrading to the current one.

   I haven't had the chance to test MacTCP 1.1.1 extensively yet,
so some of the problems with MacTCP 1.1 described below may be fixed
in this latest version. Of course, the new release may have new bugs
of its own, heaven forbid... Stay tuned for the next revision of the
notes (February 92?).

Some public domain TCP/IP applications come bundled with MacTCP.
This is somewhat paradoxical, but completely legal. The developer
has paid Apple a rather stiff fee for a "distribution license".
Technically speaking, you are allowed to use this copy only with
the application it came with. Even though such a restriction seems
a tad ridiculous, it is simply illegal to use a copy of MacTCP
obtained in this fashion with *any* other application. Another
catch is that you do not get manuals or upgrades this way, and
configuring that beast - as you will see below - may be tricky.
Finally, Apple is in the process of rehashing its policy in this
regard (setting new prices for developers' licenses etc.), so
things may change soon.


2. What is it?

   For the user, it is a Control Panel, configured just as the
Monitors or Sound CP. For applications, it is a set of procedures
which allows them to communicate with other hosts on the network
using the TCP/IP protocol. It is designed to be transparent in the
sense that once it is properly configured, any correctly written
application can make use of it without user intervention. Granted,
life without MacTCP would be hell! In practice however, both
MacTCP and the applications which use it have idiosyncrasies and
bugs which make this software difficult to handle. In my own
experience, the Mac SE is the most unstable MacTCP platform,
probably because of the peculiarities of its ROMs; but I admit
that it is a statistical observation, with no theory at all to
back it up.

Apple, in all its charming inconsistency, tells us to use their
Installer even when adding a silly little printer driver, but at
the same time does not provide an Installer script for the rather
intricate procedure of installing and configuring MacTCP.

Here's the way I've successfully done it on many machines. These
are purely empirical findings, so treat these procedures more like
a rain dance than a rational troubleshooting guide.


3. Let's do it!

   If you are installing MacTCP for the first time, or if you
suddenly run into problems such as the dreaded message "Error
opening TCP drivers - possibly no dynamic addressing", you should
follow these steps for maximum effect.

My general advice is: start with virginal (or at least freshly
updated) system files. Problems may result from improperly
installed old version of AppleTalk or other resources. For
example, I could never painlessly install new Ethernet drivers on
any Mac which previously had drivers for the Nuvolink SC box
installed on it (I don't mean to put down Nuvotech's products -
they usually work fine). What's worse, some network applications
seem to corrupt the System, and/or other important files, when
they crash. So here we go:

o  This is almost certainly an overkill, but in some cases it is
also a recipe for instant happiness. If you are having major
problems, boot from a system floppy, and trash the following from
the hard disk: System, Finder, Multifinder, MacTCP, AdminTCP,
MacTCP Prep, MacTCP DNR, all network drivers and control panels
(AppleTalk, EtherTalk, Network). These gadgets are found in the
System Folder proper (in pre-7 Systems) or in various subfolders,
such as Control Panels, Preferences and Extensions. Of course,
you'd better first back up all the files which seem important to
you, such as non-standard extensions or fonts, which will get
erased in the process! Then install a fresh system.

o  Disable all INITs, and non-essential network-related CDEVs,
especially those which may be requesting network services at boot
time (such as Network Time). Again, this probably isn't necessary,
but who knows... As is well-known, many INITs produce mind-
boggling conflicts. When you succeed in making MacTCP work without
them, you should later reinstall them one by one, checking - say -
telnet after activating each of them. If MacTCP conks out, you'll
know the culprit! If that happens, please publicize your findings,
or at least send a note to me.

o  If you will be using MacTCP over Ethernet, install network
drivers according to manufacturer's instructions. For some reason
I had better luck when I turned off AppleTalk in the Chooser
before doing this. If you are installing Apple's drivers, make
sure to use the latest Network Installer disk.

If you will be using MacTCP through the serial (printer) port,
activate AppleTalk in the Chooser now. Some Ethernet drivers, and
the MacTCP Token Ring extension, also require AppleTalk to be
active for MacTCP to work.

o  Configure the network drivers, if necessary. Most Ethernet
drivers have no user-changeable settings at all. The Token Ring
driver (configured via its Control Panel) should be set for the
correct speed (4 or 16 Mbps). It also lets you set the hardware
address of the adapter; if your site uses locally administered
addresses, you need to get one from a local administrator, and set
the driver accordingly.

If you need your Mac's Ethernet hardware address for debugging
purposes or simply for your records, you can get at it by holding
option down while clicking the "Ethernet built-in" icon in the
MacTCP panel. Another method is to log on to a nearby Unix
machine, do a "ping" to your Mac's IP address, and then tell the
Unix host to list its "ARP cache": arp -a on most systems. The
hardware address will appear next to your Mac's name as 12 hex
digits divided into pairs.

Remember that Ethernet and Token Ring handle hardware addresses
differently; if the Unix host and the Mac are on those two
different types on networks, you need to translate each pair of
hex digits into 8 binary digits, reverse their order, and
translate the whole shebang into 12 hex digits to get the real
hardware address.

o  Put fresh MacTCP, AdminTCP in the System folder. Make sure that
you are using the newest version, and not some old beta copy
obtained from shady sources. Under System 7+, they will go into
the proper subfolder automatically. If you do have to use the
older version 1.0 of MacTCP with System 7, you need to put these
files in the top level directory (i.e. don't let the Mac put them
in the Control Panels Folder; this is best done by dragging them
into an open System Folder window, rather than onto the System
Folder icon). Then make aliases to both of them and drop the
aliases in the Control Panels folder. Otherwise MacTCP 1.0 will
get confused.

o  In the next few steps in our procedure, MacTCP will create two
files: MacTCP DNR and MacTCP Prep (under System 7 the latter
should end up in the Preferences folder). You did remove the old
ones, didn't you? Since some virus protection utilities might
think that the new files that MacTCP is installing in the System
folder are viruses, it is a good idea to shut off all virus
protection before you go any further.

o  Configure MacTCP or AdminTCP (you will find more about that in
later sections). Make sure you set the right network class and
subnet mask if you use static addressing. You don't have to worry
about that if you use a server such as FastPath or EtherRoute/TCP
to assign addresses. For the time being, don't do anything with
the "gateway" (should be 0.0.0.0) and "nameservers" (blank)
fields.

o  Remember to set the correct physical layer setting ("Ethernet
Built-in", "LocalTalk", or "Token Ring") in the MacTCP panel (if
it gives you that choice).

Let me reiterate that the physical link setting has nothing to do
with the network resource (selected in the "Network" CDEV) which
you will be using for AppleTalk functions, such as printing or
AppleShare: we're dealing with strictly TCP/IP stuff.

If your Mac is using a direct Ethernet connection for TCP/IP, you
normally *don't need to* (nor should you, in some specific cases)
activate AppleTalk or choose anything in the Network CP at this
point. As we mentioned before, there are exceptions to this: some
Ethernet drivers, and the MacTCP Token Ring extension, do require
AppleTalk to be turned on in the Chooser.

If you are using TCP/IP through the LocalTalk port, you must have
activated AppleTalk in the Chooser before - otherwise that port is
simply dead, and MacTCP doesn't know how to communicate with the
outside world! On a Mac Plus, trying to reconfigure MacTCP with
AppleTalk shut off will likely result in a horrifying "address
error" or "illegal instruction" message. Don't worry - reboot,
turn on AppleTalk and see if the new MacTCP settings are still
there. If not, configure it one more time. Everything should be
fine after that.

o  Even though MacTCP doesn't always tell you to do so, REBOOT
now! Check that MacTCP DNR (and usually MacTCP Prep) files show up
in the System folder.

o  Older Macs, notably the Plus, become overworked while running
System 7 (more precisely, the newest versions of AppleTalk) and
MacTCP 1.1. Apple has released an unsupported patch which fixes
the problem. You can get it from ftp.apple.com (see section IV,
Sources, below). Do NOT install this patch unless: you have a
Plus, *and* you run AppleTalk vsn. 56 or higher, *and* you use
MacTCP 1.1. Another workaround is to use a SCSI Ethernet adapter
instead of a LocalTalk connection; the SCSI port can handle this
load, while the serial port controller can't.

o  Test MacTCP by running an application such as NCSA Telnet (the
MacTCP version, of course). If the NCSA logo quietly disappears,
you're in business. Try connecting to a *nearby* host by giving
Telnet its decimalized IP address, such as 138.87.132.21.

As of this writing, newest versions of NCSA/BYU Telnet sometimes
produce a system error when they're run on a Mac Plus under pre-7
System. This might indicate a serious problem, but in 9 cases out
of 10 this happens only the first time you attempt to run Telnet.
Reboot and try again.

o  Assuming all went fine, you can now set the AppleTalk link in
the Network panel if you wish (if AppleTalk was off, that is; this
should also automatically turn on AppleTalk in the Chooser, but
check it just in case). There are some exceptions here. For
example if your Mac is on Ethernet, which in turn is connected to
a Token Ring with the IBM 8209 bridge, activating AppleTalk might
screw up TCP/IP. Details available on request.

o  If you can't connect to remote hosts, check if the "default
gateway" field in MacTCP changes from the original 0.0.0.0 to
something else after you start telnet or other MacTCP software. If
it doesn't, then your Mac is having trouble discovering a gateway
which connects your LAN with the rest of the world. You need to
tell MacTCP where it is: enter its numeric IP address in the
"default gateway" box. You may also want to tell it where the
local nameserver for the root domain is (put a period in the
"Domain" field, enter the IP address in the box next to it, click
Default). To be on the safe side, trash MacTCP DNR and MacTCP Prep
again; be sure to reboot the computer.

o  You should now be able to telnet to a remote host, and Telnet
should be able to resolve symbolic addresses for you: e.g.
nic.ddn.mil or sumex-aim.stanford.edu.

If after all this you are still having problems, first check the
hardware (is Ethernet up? are plugs plugged in? switches switched
on? gateways are gatewaying? etc) Next, consider the possibility
that some other node is using your IP address. See if things work
if you change the IP address to another one from the range
assigned to you. When MacTCP loads, it in effect asks the network:
"host with IP number so-and-so, please respond". Your Mac's IP
address is used in that query. If there is no answer, all is good.
But if something out there responds, MacTCP correctly assumes that
there is a conflict in IP numbers, and returns an error code which
most applications then translate to a less-than-helpful message
like "MacTCP is not installed correctly", or "Error opening TCP
drivers - possibly no dynamic addressing".

If all of the above doesn't help, buy a pair of tickets to Jamaica
and invite your high-school flame along. After all, will you let a
piece of steenkin' iron drive you nuts?!


4. Details...

In the description below, we use the MacTCP control panel. The
only difference between it and AdminTCP is that the latter allows
you to lock and unlock the former; other than that, they are
functionally identical. If the MacTCP panel you have has been
locked, you won't be able to make any changes to it; you have to
unlock it with AdminTCP first, or simply make all changes from
within AdminTCP.

After opening the MacTCP control panel, you should first set the
physical link for the TCP/IP connection; for instance, if you use
MacTCP on a LocalTalk network - whether gatewayed to an Ethernet,
or isolated - select the "LocalTalk" icon. If you are directly on
Ethernet, click the "Ethernet Built-in" icon.

Now click the More button. In the first stage, you will be setting
only three things: address assignment mode, network class, and
network subnet.


-  If you are a "trusted and permanent" user who received a
specially assigned IP address, click the "Manually" radio button.
As a rule, it is best to have a permanent, static IP address. Some
networks, however, have more nodes than addresses available to
them. Such institutions resort to assigning addresses dynamically
to those hosts (usually PCs) which request them; see the next
subsection.

Please remember that choosing an address at random will at best
make your connections unreliable; it can also provoke unrestrained
wrath of some powerful people in your organization. Courts have
been known to drop bodily harm charges under much weaker
extenuating circumstances. Moreover, some network numbers are
illegal on the Internet. If you pick one of those, you'll be
asking for a lot of trouble - in particular, you'll be getting all
e-mail addressed to the University of Mars for the rest of your
life.

o  The IP number you were assigned determines the network class.
MacTCP is smart enough to figure it out by itself. You can also
set it manually: addresses beginning with 1-127 are class A, 128-
191 indicates class B, and 191-254 are class C. Make sure you know
what you are doing.

o  The netmask can be determined by stopping a friendly
administrator in the hall and asking one or two simple questions.
"Do we use subnetting?" And, "If so, how many bits form the subnet
number?" If the first answer is "no", then slide the subnet mask
indicator as far to the left as it will go. Such masks are
255.0.0.0 for class A networks, 255.255.0.0 for class B, and -
guess what - 255.255.255.0 for class C.

If your site does use subnets, the plot thickens. A number of
address bits is set aside as the subnet number. You have to enter
the subnet mask (such as 255.255.255.0, eight bits determining the
subnet in a class B network) in the appropriate field; or you can
delicately slide the subnet indicator to the right until it marks
the right place. For example, if 6 bits are reserved for the
subnet, you slide the thing from the leftmost position to the
right by six little notches.

Be forewarned: it is vital that all hosts which have the same
network part in their address use identical subnet mask. You can
avoid a lot of desperation in the future if you make sure you get
this straight. 'Tis the time to read the manuals, perhaps?

o  Get out of the "inside" panel by clicking OK. Type your IP
address in the edit field in MacTCP. Go back to the subpanel to
verify everything is as it's supposed to be. If anything has
changed all by itself, you are probably trying to set a wrong
network class.


-  If you were told that "dynamic address assignment" is available
to you, then all you need to do is click the Server radio button
in MacTCP. Things should work automagically thanks to built-in
intelligence of devices such as the FastPath, GatorBox, or
EtherRoute/TCP. If there are problems, you have to get together
with the person who maintains your gateway.

-  Many people prefer to avoid the "dynamic" button in MacTCP.
Others have been using it successfully. There are situations when
Apple's "dynamic addressing" is called for, but don't use it
unless you have to.


After you have entered all the required information, and you
suspect that the user has itchy hands, it's time to click the
"protected" box, close the panel and reboot right away. Remember
to trash AdminTCP from his disk after you are done setting things
up.

If the user is likely to heed your advice, but might accidentally
change the settings, click the "protected" box in AdminTCP, tell
him not to fiddle with AdminTCP, and leave the control panel on
his disk. This will save you some time and trouble when you have
to change his settings again.

If the prospective user is a TCP/IP sage, then you of course leave
things wide open for him to play with the little buttons during
long winter nights.

There are some other permutations involving, for example, locking
just the network part of the address, but leaving the subnet and
node numbers accessible. Please read the manual!


5. More details

After you have coerced MacTCP to work with this basic
configuration, you may want to enter a few more things.


The "Gateway Address" field in the MacTCP control panel should
contain the IP number of the default gateway, i.e. the place where
MacTCP should send packets if it doesn't know what else to do with
them (i.e. packets addressed to a remote network). On most
networks you will leave that field set to 0.0.0.0, and MacTCP will
locate the default gateway by means of a magic wand called Routing
Information Protocol (RIP).

If your network for some reason does not implement RIP, you must
enter a "real" address there. For example, if your Mac is on
LocalTalk, you would use the address of a FastPath or another
device which connects your network with the Ethernet. If you are
directly on Ethernet, you should use the address of the router
which connects that Ethernet to the campus network, or - if you
don't have routers - the gateway which links your outfit with the
rest of the world.


You will also want to tell MacTCP where to find nameservers. Going
into the details of the Internet Domain Name System (DNS) would
make this document twice as long, so we will stick with the
basics. The Domain Name System is used by computers to convert the
human-friendly names such as "spider.math.ilstu.edu" to numeric
addresses (IP numbers) such as 138.87.132.21. On occasion,
computers use this system to "reverse-map" numeric addresses, i.e.
to verify that your numeric address does correspond to a name
which recognized by the DNS.

If your network is connected to the Internet, your computer lives
in some well-defined "domain". In my case, it is math.ilstu.edu,
and a machine with address 138.87.132.21 is providing name service
for that domain. I thus enter "math.ilstu.edu." (no quotes, but
note the period at the end!) in the Domain field, and
138.87.132.21 in the Server field next to it. I also click the
Default button. This informs MacTCP that my computer is in the
math.ilstu.edu domain, so when I tell my Mac to telnet to "koala",
it will query the nameserver about the address of the computer
"koala.math.ilstu.edu". Here is the first row of edit fields on my
Macs:

 --------------------------------------
| math.ilstu.edu. | 138.87.132.21  | x |  ("default" button on)
 --------------------------------------

If the local nameserver doesn't keep a large table of addresses,
or if it is less than reliable, you will probably want to put in
some backup servers in fields below. In particular, one or more
Domain fields could contain the period alone ("root domain", i.e.
the entire Internet) with the address of a big, reliable machine
next to it.

Clicking the "default" button by no means guarantees that this
particular server will be consulted first; MacTCP first contacts
those nameservers listed in the control panel which seem to match
the domain name included in the query - and only if that fails,
the default server is asked as a last resort. However, all domain
name queries should generally go to your local nameserver first.
You may want to enter your local nameserver's address in the
second row as well, specifying the root domain (period) in the
first field. In my case, the second row would thus look like this:

 --------------------------------------
|   .             | 138.87.132.21  | o |  ("default" button off)
 --------------------------------------

A small text file called Hosts can be put in the System Folder
proper. I was told that some applications (e.g. VersaTerm)
automatically create this file and modify it when needed. The
Hosts file lets you enter additional information which MacTCP
uses. For example, I could enter

spider.math.ilstu.edu.   IN   A   138.87.132.21
math.ilstu.edu.          IN   NS  spider.math.ilstu.edu.
rs6000.cmp.ilstu.edu.    IN   A   138.87.1.2
rs6000.                  CNAME    rs6000.cmp.ilstu.edu.
ilstu.edu.               IN   NS  rs6000.cmp.ilstu.edu.

there to tell MacTCP that the computer spider.math.ilstu.edu has
address 138.87.132.21, that it is a nameserver for my domain, that
rs6000 in Computer Services has address 138.87.1.2, that I connect
to it often enough so I want my Mac to use rs6000.cmp.ilstu.edu
whenever I say "rs6000" (otherwise MacTCP would be looking for
rs6000.math.ilstu.edu!), and that it is a nameserver for the
domain directly above me.

The use of periods at the end of domain names guarantees that
MacTCP treats them as "absolute names", and doesn't try to append
anything to them. If you know what you are doing, you can work
with relative names (without the period) saving some space,
typing, and quite possibly reducing the amount of memory MacTCP
consumes - the current MacTCP implementation is rather limited in
this respect. Assuming that my Macs are placed in the domain
"math.ilstu.edu" by using the 'default nameserver' button in
MacTCP, I could simply use "spider" instead of the absolute
"spider.math.ilstu.edu.", because that extension would be
automatically appended to a relative name without the period.

For a list of specifications allowed in the Hosts file, see the
MacTCP manual.

After modifying the Hosts file or the nameserver information in
the MacTCP control panel, make sure to trash the MacTCP DNR file,
and reboot right away.


6. Odds and ends

We end this section with a few miscellaneous problems reported in
Usenet newsgroups or in personal communication.


Sometimes the physical link icons (usually the "LocalTalk built-
in" icon) mysteriously disappear from the MacTCP control panel.
This seems to be caused by a bug in the recent Network Software
Installer from Apple.

If the MacTCP panel does not show any choices at all, it might
help to zap the parameter RAM by holding down:
command-option-p-r while restarting the mac (system 7)
command-option-shift while opening the Control Panel (pre-7 systems)
(reported by Mike Wiese of MIT in a Usenet posting).

I haven't had much luck with this fix. Running System 7 and the
TuneUp extension on a Mac broken in this fashion, I found that I
had to reinstall the system and network files from scratch, then
install, configure and test MacTCP, and finally install the TuneUp
as the last step.


Don't disregard the physical connection. I've seen several reports
of strange problems which were eventually traced to a bad wire or
transceiver. Some of Apple's "FriendlyNet" cables for use with the
Quadras were involved. Borrow a working transceiver and cable from
someone and try it before blaming everything on the software.


Are things messed up, and you are stuck? Make sure to contact the
vendor of the network adapter. There may be a problem which they
know about. You may need to get an updated driver from them.


It was reported that the Apple cache card (for the IIci) used to
cause problems with MacTCP and a lot of other things. Scream for a
replacement!


Some cases of MacTCP applications freezing some machines (notably
older SE's) seem to be caused by bad karma between MacTCP and the
system ROMs. Matthew D. Heys a while ago reported extensively on
his experiments. He empirically demonstrated that the freezes
happen after a "cold start" (i.e. powerup), but do not occur after
the computer is restarted with the programmer's switch or with the
"Restart" in the Finder's "Special" menu.


III. Applications

There are many commercial programs which use TCP/IP connectivity
(InterCon's family of networking applications, or VersaTerm from
Synergy Software). I will not review them here because I have had
little or no experience with them. Let the vendors speak for
themselves. Some makers of similar commercial products are
mentioned in Section IV for your convenience.

The list of public domain or shareware software which follows will
hopefully be amended and expanded in the near future - please send
in your favorites!


1. Terminal emulation

There are currently two popular freely available programs which
let the Mac connect to other hosts as a terminal using TCP/IP
(telnet): NCSA Telnet and its derivative, tn3270.

The first one is being developed at the National Center for
Supercomputing Applications in Urbana-Champaign. It emulates a
vt100 terminal and provides some Tektronix graphic terminal
capabilities; it also implements an ftp server function, i.e. when
it's running, you can ftp *from* other hosts *to* your Mac. NCSA's
version was modified somewhat by the Brigham Young University;
NCSA/BYU Telnet implements a simple ftp client function.

The second, tn3270 written at Brown University, is a variant of
Telnet which provides the IBM 3270 terminal emulation. It also
supports file transfers and printer sessions, but I don't know
enough about our IBM big iron to actually try them out...

NCSA Telnet comes in two versions: one which relies on MacTCP, and
one which includes built-in TCP/IP drivers. If all you need is
terminal emulation, the second version might be for you.

Stanford University has developed a comprehensive package of
TCP/IP applications collectively known as SU-Mac/IP. I didn't have
a chance to try it. One advantage of Stanford's software is that
it reportedly gives more informative error messages, which can be
a great asset - especially when you are having problems! Contact
[e-mail] for conditions of a site license. If
you know how to use MacBinary FTP, you can download the entire SU-
Mac/IP documentation in MS Word format from jessica.stanford.edu
(directory netinfo/macip/manuals4.0/users).


2. E-mail

There are several schemes in which a Mac can access Internet mail.
The crudest way, of course, is to telnet to a host on which you
have an account, and use that host's mail facilities. Another is
to keep using whatever mail system you have on the AppleTalk
network (e.g. QuickMail or Microsoft Mail), and then provide a
SMTP gateway which will translate it to Internet mail; this tends
to be expensive and sometimes unreliable.

By far the most popular and convenient system is the client/server
method, in which one computer uses its powerful mail software and
provides service to clients such as Macs or PCs. Macintosh users
have the good fortune of being able to use some excellent mail
clients which work on a Mac. Eudora written by Steve Dorner
leads the pack (in my humble opinion), with MIT's Techmail a
close second.

Eudora and other similar clients allow the user to read, compose,
and edit mail on the Macintosh desktop; it can print mail, save
messages as Mac files, and attach Macintosh-specific files (say,
formatted Word documents or even applications) to the letters
using the Macintosh standard BinHex encoding scheme (see Appendix
A). When it's time to process mail, Eudora contacts the server,
uploads messages waiting to be sent and downloads those which the
server received for you. The (supposedly) well-maintained and
well-connected server computer handles the rest, so you don't need
to know anything about Unix or any other alien operating system.

A special "Post Office Protocol" has been defined to handle this.
There are two versions of it: POP2 and POP3. The server and the
client have to agree on the version they speak. Most Mac clients,
in particular Eudora, are POP3. If you succeed in sending mail,
but attempts to check incoming messages fail, then it is very
likely that your POP client and server use different versions of
the protocol.

It is easiest to set up a POP server on a Unix computer (popper
from UC Berkeley seems to be the way to go here), but there are
also servers operating under other systems, including one (POP2)
which runs on a Macintosh. If you use a VAX with VMS, and some
TCP/IP package is already installed, chances are that it includes
a POP server. There is also a public domain POP3 server for VMS
available from Indiana University, which a dear friend of mine, a
computer semi-literate, got up and running without much grief.
Talk to your local system administrator.

For those of us who need to worry about PCs too, POPmail from
University of Minnesota runs on MS-DOS machines and is compatible
with both POP2 and POP3. A POP2 server running on a Mac is also
available from that site.

A Macintosh mail client is also included in Stanford's SU-Mac/IP
package, available for a nominal fee.

In case you don't have a reliable machine which may be used as a
POP server, don't worry; your Mac can be made into a full-blown
SMTP mailer, and it then behaves like any other "real" Internet
mail node. Get Lee Fyock's LeeMail and try it out. I haven't, so I
can only rely on second-hand reports which say that LeeMail might
not be as smart as a full-blown Unix mailer, but it works just
fine.

Finally, a Swedish offering - MacPost - is something of a mixture
of both methods; it has both a client and a server running on a
Macintosh, but requires a Unix host as an intermediary for outside
mail. The transactions between the individual clients and a
MacPost server only use AppleTalk, and TCP/IP is only needed by
the server Mac to communicate with the Unix host. I haven't used
this one either, but who knows - it might be just the thing for
you.

Steve Dorner occasionally posts his much more complete list of Mac
POP clients (including commercial ones) to newsgroups such as
comp.protocols.appletalk and comp.sys.mac.comm.


3. FTP

As we mentioned above, Telnet has limited ftp capability. But two
other applications, XferIt and Fetch, are specifically designed to
provide "FTP with a human face". Both present the directory on the
remote host as a Macintosh dialog window, in which the user can
select files to be downloaded. I've found minor quirks in both of
them, but overall they are extremely impressive and useful. There
is also HyperFTP, a HyperCard stack which is similar to the two
applications. It is very solid, but relatively slow, and -
naturally - it requires a reasonably recent version of HyperCard
and consequently quite a bit of RAM.

As with telnet and mail, an ftp application is also available as
part of the SU-Mac/IP software.

When using FTP from a Mac, you should realize that many anonymous
FTP sites do not allow connections from hosts which are unknown to
the Internet nameservers. To connect to such nodes, your Mac's IP
address has to "reverse-map" to a legal Internet name, like
mac1.math.ilstu.edu. The system administrator of your nameserver
computer might be willing to enter your address in his database.

See Appendix A for a very short introduction to the intricacies of
Macintosh file transfers. For more information on the procedures
involved in FTP'ing Macintosh files, read the text file ftp-
primer.txt, which can be found on sumex-aim.stanford.edu in the
directory info-mac/reports.


4. Network news

As with FTP, there are three applications and one HyperCard stack
designed to let you access news: TheNews, Newswatcher, NetNews
(stack), and Nuntius. I have not experimented with Nuntius, so I
can only quote second-hand information: at least one of my
correspondents swears by Nuntius as "the best newsreader I have
seen on the Mac by far".

There are minor problems with each of the three, compounded by the
fact that this method of reading Usenet articles usually involves
downloading humongous lists of articles over a slow connection
such as overloaded LocalTalk, keeping track of read items, and so
on. This is not for the faint of heart. Many people still stick to
the old-fashioned method of logging on to a bigger host and
reading news there. But when it works, it's worth it! You can
finally organize the saved articles on your own disk, use your
favorite word processor to write replies, etc. I hesitate to
recommend specific choices, but personally I have found the newest
NewsWatcher to be very stable, powerful and easy to use.

News clients require an address of a nearby friendly NNTP server.
The server needs to be friendly in the sense that it must
recognize your Mac as a host which is allowed to post news. This
also requires having a valid domain name (see above under FTP),
and the server must have been configured to accept uploads from
your computer. Even though many servers allow free read access but
limit posting, the Mac clients will usually give up without
explanation unless they are granted both permissions. This causes
a lot of confusion among novice users, who later post complaints
about "broken newsreaders".


5. Miscellaneous gadgets

There are dozens of useful or simply nifty applications which use
MacTCP. Here are two of my favorites.

Network Time written by Peter Resnick is a CDEV which periodically
contacts an Internet timeserver, like merit.edu or nic.ddn.mil,
looks at the Map CDEV to determine your location (and hence time
zone offset; I particularly like this elegant touch), and sets
your Mac's clock. After installing it you can boast that your
screen clock is accurate to a tiny fraction of a second.

Finger and fingerd by Peter Lewis give Macs the Unix "finger"
capability. Finger sends a finger query to a remote host; it's
even smart enough to automatically put people whom you "finger-ed"
in a menu, so you don't have to type their address again. Finderd
simulates a finger daemon on your Macintosh, so other people can
finger you while you are simply working on your Mac.

Peter has released another fine product - Talk, which simulates a
Unix "talk" client and daemon on the Macintosh. A third gadget
written by him, Chat, turns a Mac into a simple conferencing
center (a la IRC, for those who have used it). Peter's latest
product, ftpd, runs in the background under System 7 and makes the
Mac into an ftp server.

The Internet Gopher searches "gopher servers" on various Internet
hosts and retrieves various information such as directory entries,
class schedules, campus newsletters, etc. One Macintosh client is
a HyperCard stack written at University of Minnesota. It has been
recently superceded by an application called TurboGopher, which
definitely lives up to its name. Another standalone version,
GopherApp - still a bit quirky (e.g. it cannot retrieve documents
larger than 50KB or so) but promising - comes from Indiana
University.

Wide Area Information Service is a fruit of a joint project of
Apple Computer, Thinking Machines, Peat-Marwick and Dow Jones.
There are several WAIS servers in operation; they can be queried
from a Mac by means of an application called WAIStation. A WAIS
server can also be accessed by telnet to quake.think.com (login
name wais), but the interface is then much less friendly. Check it
out! It's a glimpse at the things to come.

There is no doubt that someone out there is sweating over a Mac
version of the Archie client (for searching directories of
anonymous ftp servers), but I'm not aware of a finished product.

MIT's TechInfo is another impressive example of a fast and easy to
use information retrieval system. MIT and a few other institutions
run servers which store and search databases of campus events,
faculty and student directories, etc. Both Mac and PC clients are
available.

If your Macs use the CAP AppleShare server, chances are you'll
want to look at MacDump, which permits automated backups of your
Mac volumes onto the CAP server.

A desk accessory called Client DA (written by Greg Anderson of UC
Santa Cruz) connects to the Unix daemon "supersrv" (by Steven
Grimm), which in turn uses the wonders of Unix to do whatever you
want it to do. For example, a trivial Unix shell script invoked by
supersrv allows our faculty to search all users on the system, or
access the archie ftp search facility directly from their Macs.
Client DA has some problems with smaller Macs, and I wish someone
kept maintaining this wonderful gadget.

On the lighter side, we have GameMaster, which lets you play a
variety of games over AppleTalk and TCP/IP networks.

There is also a Macintosh version of ping, called Mping; it is
available from ftp.apple.com as one of the examples of a TCP/IP
application (file /dts/mac/netcomm/mactcp-1-1-examples.hqx).

There is a bare-bones prototype of an SNMP management console on
ftp.apple.com, in the file /pub/apple-ip/snmptool1.0d7.sit.hqx. I found
it to be quite buggy (maybe I just don't know how to use it). But I did
manage to obtain all data from my EtherRoute gateway using it.

Please let me know what are your favorites in this category - I'll
be happy to expand this section!


IV. Sources

1. Downloading text files

Use any account available to you on a well-connected host. Type
"ftp sumex-aim.stanford.edu" (or if that doesn't work, try "ftp
36.44.0.6"). Type "anonymous" as login name, and your mail address
as password. In 9 cases out of 10, archives such as this one
accept "ftp" in place of "anonymous", which means that you can
delay the onset of carpal tunnel syndrome. You will also discover
that many sites will accept any password at all, but let's be nice
to those folks who specifically ask for the real id.

Enter "cd /info-mac/report", and then "get ftp-primer.txt". When
you see "Transfer complete", type "quit" and read the file you
just downloaded.

After becoming skilled in using ftp, download some more text files
from the /info-mac directory:

help/accessing-files.txt
report/how-do-i-find.txt
report/internet-access-11.hqx
report/ftp-sites.txt

A Macintosh communications FAQ ("frequently asked questions") list
is an invaluable source of information. It is posted periodically
in the Usenet newsgroup comp.sys.mac.comm; it is also available
for anonymous ftp on rascal.ics.utexas.edu as communications.FAQ
in the directory mac/faq.

The anonymous ftp site nnsc.nsf.net run by the National Science
Foundation is a good source of background information about the
Internet (see directories /nsfnet and /info).


2. What next?

When you have learned how to download Macintosh executable files,
it's time to go hunting for specific applications.


WARNING!!!
The minute you start downloading files from the network, you
become more susceptible to viral infection than before. I strongly
suggest that you should first get and set up the wonderful free
virus checker, Disinfectant. Its home is ftp.nwu.edu, in directory
/pub/disinfectant; it can also be found in many other places, e.g.
on sumex-aim.stanford edu in the directory /info-mac/virus. You
may then want to send its author, John Norstad, a nice thank-you
note: we all owe him a great deal! If you have access to Usenet
news, make it a habit to monitor the comp.sys.mac.announce group:
it is probably the most reliable source of inform
ation about newly
discovered viruses.


Here is a list of applications which were mentioned above, and
which can be found on sumex in the directory /info-mac. There are
many servers which maintain copies of /info-mac contents, such as
wuarchive.wustl.edu in /mirrors/info-mac. The names are aren't
exact: many version numbers have certainly advanced quite a bit by
the time you read this.

comm/chat-10.hqx
comm/fetch-21.hqx
comm/finger-135.hqx
comm/hyperftp-13.hqx
comm/lee-mail-124.hqx
comm/ncsa-telnet-25.hqx
comm/news-watcher-102.hqx
comm/nuntius-111d12.hqx
comm/the-news-22.hqx
comm/xferit-14.hqx
cp/network-time-111.hqx
game/game-master.hqx


Software found on ftp servers other than sumex:

ClientDA:         ssyx.ucsc.edu (supersrv is there as well)
Eudora:           ftp.cso.uiuc.edu in /pub/mac/eudora
                  (also on ftp.qualcomm.com)
GopherApp:        ftp.bio.indiana.edu in /util/gopher
MacDump:          bbn.com
MacPost:          pollux.lu.se in /pub/mac/comm
MacTCP+ patch:    ftp.apple.com in /ftp/dts/mac/netcomm
MPing:              as above, file name mactcp-1-1-examples.hqx
NCSA/BYU Telnet:  bert.cs.byu.edu
NetNews:          ftp.bio.indiana.edu in /util/mac
POPmail:          boombox.micro.umn.edu, in /pub/POPmail
popper:           lilac.berkeley.edu
SU-Mac/IP:        send e-mail to [e-mail]
TechInfo:         net-dist.mit.edu in /pub/TechInfo
TechMail:         net-dist.mit.edu in /pub/TechMail
tn3270:           brownvm.brown.edu
TurboGopher:      boombox.micro.umn.edu in /pub/gopher
WAIStation:       think.com in /wais

A list of anonymous FTP sites (not only Macintosh-related) is
maintained on pilot.njin.net. Many Unix hosts (and an increasing
number of other machines) will also let you search an archie
database of anonymous ftp sites.

This should keep you busy for now...


3. Contacts for commercial products

Please remember that I do not in any way endorse commercial
products by listing the vendors here, and I'm not in any way
associated with them. This is simply for your convenience. Phone
numbers are followed by an anonymous ftp server which can be used
to get free upgrades and information, or an e-mail address.

Cayman Systems         [phone]    ftp.cayman.com
Compatible Systems     [phone]    csn.org, in /compatible
Farallon Computing     [phone]    farallon.com
Intercon Systems       [phone]    [e-mail]
Shiva                  [phone]    shiva.com
Synergy Software       [phone]    [e-mail]
Webster Computer Corp  011(?) 61 3 764 1100  (Australia)


4. Let's end with a short sermon...

Many of the applications mentioned above are NOT in public domain.
They are either shareware, or there are restrictions on their use
and/or distribution. PLEASE PAY FOR SHAREWARE YOU KEEP!!! Author's
address can almost always be found by pulling down the Apple menu
and selecting "About..." Let's keep this wonderful, affordable
software alive!


Appendix A. Peculiarities of Mac file transfers

Macintosh files differ from files on most other machines in that
they consist of two parts. One contains data (text, executable
program), and the other - resources (icons, the file's creator
code, etc.) I'm simplifying a little, but never mind. This
complicated structure prevents us from sharing such files directly
over the network.

Moreover, there is only one language which practically all
computers understand: the ASCII code (plain text). Even though
this isn't a terribly elegant solution, we simply bring everything
to this lowest common denominator to assure compatibility. For
example, in order to send a file to someone by the current e-mail
systems, it has to be somehow encoded into an ASCII file.

The Mac community has pretty much agreed on a common standard for
doing just that: BinHex. BinHex swallows a Mac file, icons, file
creators and all, and converts all that into a plain text file
filled with something that looks like garbage; it also performs
the reverse procedure. So you need BinHex.

There is one obvious difficulty, however: how do you get a BinHex
decoder (a Macintosh application!), when you don't have BinHex?
You will also need software which will somehow let your Mac do
FTP. The easiest way to "bootstrap" yourself is to simply get a
copy of such a beast from a local Mac guru or a Mac User Group. If
you're lucky, you will lay your hands on an FTP utility which can
also de-BinHex files, such as XferIt or Fetch. You can then tell
it to connect directly to, say, sumex, dowload the interesting
BinHex'ed files, and decode them while they arrive. Similarly,
newer Gopher clients, such as the TurboGopher mentioned above, can
download and decode BinHex'ed files. I'm also told that Gopher is
now the preferred method of accessing the sumex.stanford.edu
archive.

Another way is to get NCSA Telnet, log on to a friendly Internet
machine, download the applications you need to that computer in
*binary* form (e.g. the file binhex4.bin available on sumex in
/info-mac/util) using the binary mode in ftp. Then connect back to
your Mac using the Telnet FTP server and put the files on the Mac
using the MacBinary mode... It sounds (and is) a bit complicated,
but remember - this convoluted process is necessary only in the
very beginning.

Once again, we have just licked the surface of this topic here.
For more information, see the file /info-mac/report/ftp-primer.txt
on sumex-aim.stanford.edu.


Appendix B. Mac networking: mini-tour

In the networking world, it is easy to drown in the alphabet soup
and the sea of obscure terms. But understanding the process by
which computers communicate helps troubleshoot problems. We will
go through some elementary information in this appendix. Things
may get a bit confusing, and you may want to read what follows two
or three times until it makes sense...

For two digital devices to talk to each other, there must be a
physical connection between them (a wire, optical fiber, radio
link, etc.) and an agreement as to the logical organization of the
information. In computerese, such mutual understanding is usually
called a "communications protocol".

Apple's Macintoshes use a "native" set of protocols, collectively
known as AppleTalk. The physical aspect of AppleTalk is, very
simply, the kind of wires the device uses. If you stick a little
round connector into the printer port of your Mac, or in the jack
in your LaserWriter, you are using AppleTalk over Apple's original
slow wiring, i.e. LocalTalk. Almost nobody uses that now -- even
Apple's own network uses Farallon's Phonenet system, but that is a
technical detail. You are on LocalTalk.

If your Mac has an Ethernet card or external adapter attached, you
will be using AppleTalk on a physical Ethernet network; that is
called EtherTalk. Similarly, if you install a Token Ring adapter,
the incarnation of the AppleTalk protocol you are dealing with is
called TokenTalk.


The logical layer of AppleTalk handles details such as how two
Macs can discover each other on the network, how individual nodes
are uniquely identified, what should a Mac say to a printer or an
AppleShare file server when it wants to use it, and so on. The
devices you see in the Chooser (LaserWriters, file servers, or
routers such as Netway or SNA@ps) are all AppleTalk devices. The
beauty of AppleTalk is that you don't really care what physical
method you use. You may see a printer on LocalTalk, or a
LaserWriter IIg on Ethernet, or a Netway box on Token Ring -- it
doesn't matter.

But the nitty-gritty of how the actual network operates does vary
from one kind of wire to another. The computer has to behave
differently on each kind of network, but of course you don't want
to know about that! Enter "network drivers": low-level pieces of
system software which take care of that. When you put in an
Ethernet card, you need to install the EtherTalk drivers in your
system. Same with TokenTalk drivers. It's like speaking with
someone over the phone, or on a walkie-talkie. The principle is
different, but the message is the same.


There are more and more ways of making non-Apple devices speak
AppleTalk: that's why there are MS DOS computers on LocalTalk
networks, Novell AppleShare servers, and you can configure your
Sun Sparcstation to print on an Apple LaserWriter. The Internet
world, however, doesn't know the first thing about AppleTalk. It
only understands the collection of protocols known as TCP/IP. What
does TCP/IP have to do with AppleTalk? The answer is "not much",
and "nothing" most of the time. Putting a Mac on a TCP/IP network
is like dumping an Englishman in the center of Beijing: there is a
language barrier.


MacTCP, the gadget we are discussing in this guide, allows Mac
applications to use network interfaces -- such as the built-in
LocalTalk port or an Ethernet card -- to transmit and receive data
packets which contain TCP/IP information, and hence to communicate
with the millions of other TCP/IP computers on this planet.

Just like Apple came up with specifications for sending the high-
level (AppleTalk) data using the various low-level, network-
specific "transport protocols" (Ethernet, Token Ring etc.), the
Internet has standards for sending the high-level TCP/IP data
using the low-level network mechanisms. Ethernet is the best
choice, since the Internet protocols were "born" on Ethernet, so
those standards are well-established.

Apple adopted a certain way of sending TCP/IP data wrapped inside
LocalTalk packets, and MacTCP knows how to handle this. It puts
("encapsulates") TCP/IP information into a normal LocalTalk
packet, and sends it out. That packet makes absolutely no sense to
any AppleTalk device (it looks like it has garbage inside), except
those which use MacTCP to do the reverse decoding.

A standard for transmitting TCP/IP data in Token Ring packets has
also existed for quite some time. But MacTCP did not know about
it, until Apple released an add-on "MacTCP Token Ring Extension",
which -- again -- takes a TCP/IP packet and beats it into shape
before sending it through a Token Ring card.


To make things more interesting, MacTCP used on Ethernet (or Token
Ring) is capable of two different behaviors: it can take the
TCP/IP data and spit it out unadorned, according to the usual,
world-savvy IP-on-Ethernet or IP-on-Token Ring recipe. But it can
also be set to use EtherTalk (respectively, TokenTalk), which
means that it will activate the wrapping/unwrapping AppleTalk
filter between the network interface and the application software!
The general idea is *not* to use EtherTalk or TokenTalk in MacTCP.
The reason should become clear soon.


To summarize, here are some scenarios. (a) Mac on Ethernet, MacTCP
correctly installed, "Ethernet built-in" set in the MacTCP control
panel; (b) Mac on Token Ring, MacTCP installed, the Token Ring
driver installed and configured properly, TokenRing selected in
MacTCP. All is peachy. A TCP/IP-aware application on the Mac (such
as NCSA Telnet, etc. -- see Chapter III) wants to communicate with
a Cray at the Space Station "Freedom", which by the time I finish
this will be in orbit. It tells MacTCP to send out a Telnet
packet, MacTCP translates it into the standard format for Ethernet
or Token Ring, some gateways down the road convert it to the
TCP/IP over radio waves form, the packets gets to the Cray, it
says "Aha! we've got a hacker trying to log in here", and so it
goes.

Now for something more mundane. (c) Mac Plus on LocalTalk, MacTCP
installed, "LocalTalk built-in" selected in the MacTCP panel (the
only possible choice!). A TCP/IP "datagram" goes out after being
wrapped into an AppleTalk packet! Now, the LocalTalk is no doubt
connected to the outside world one way or another. If that's done
using a relatively unsophisticated device, it will take the data
and simply convert it to an equivalent EtherTalk, TokenTalk, or
whatever packet. That one goes out allright, gets up to the Cray,
but it now says: "Phooey, that's something I don't understand! It
has some strange stuff inside! Let's quickly drop it on the
floor." The reason is that most Internet hosts, like our Cray, are
not instructed by their software to go deeper inside the packet
and actually recognize that it was TCP/IP information wrapped
inside AppleTalk... and why should they bother? What is needed is
a more sophisticated gateway between the LocalTalk and the outside
network.

Scenario (d): Mac Plus on LocalTalk sends a TCP/IP-in-AppleTalk
packet which is directed towards a "DDP-IP gateway", such as the
Fastpath, Gatorbox, EtherRoute/TCP, etc. The gateway's software is
smart enough to look under covers and see what is hiding inside.
If it sees TCP/IP data wrapped inside AppleTalk, it strips the
outer layer and passes the raw IP information in the standard
format to the Ethernet network. All is well again! LocalTalk-to-
Ethernet gateways like that are common, but equivalent ones for
Token Ring are still scarce and expensive.

How about (e): just like in scenarios (a) or (b), except MacTCP is
set to use EtherTalk (or TokenTalk). Now regular TCP/IP packets
will not be coming through -- MacTCP simply ignores them! It
expects AppleTalk packets only. It will be able to communicate
with the Mac Plus in (c), but not much else. So let's just forget
it and stop here...


Appendix C. Dial-in access

In our personal opinion, the most elegant way to connect a Mac to
a TCP/IP network is AppleTalk Remote Access (ARA), a commercial
product of Apple Computer, bundled with PowerBooks, and sold as a
separate product.

ARA uses the Communications Toolbox (built into System 7, and
installable in System 6.0.x) to ship AppleTalk packets over a
modem to an ARA server, which is presumably connected to a "real"
network. MacTCP in turn uses the AppleTalk protocol to transmit
"wrapped" TCP/IP packets (if it is configured to communicate via
AppleTalk). This results in a two-stage translation: TCP/IP-to-
AppleTalk, and AppleTalk-to-modem. The data have to be decoded by
a reverse process at the other end.

This explains the only major drawback of ARA: speed. A 2400 baud
modem is next to unusable in this configuration. But a 9600 baud
connection should provide decent response even with the additional
IP encapsulation.

The server Mac, whether it's on Ethernet or LocalTalk, spews out
AppleTalk packets, from which the TCP/IP information has to be
reconstructed by an IP gateway. If you don't have a gateway such
as the Fastpath, GatorBox, EtherRoute, or MultiGate, you can't use
ARA for TCP/IP access to the network.


Since for most of us the primary Internet application is e-mail,
we will mention the "poor man's" dial-up connections which can be
used with the mail client Eudora. You need to know how to edit a
program's resources to patch Eudora in this fashion -- a task
which is not for the faint-hearted. The two alternatives are:

 i) modify "stock" Eudora to navigate through a simple modem
    connection;

ii) use the Simon Fraser University version of Eudora and create
    an intelligent connection script.

The first method is described in the Eudora Q&A stack available
from uxc.cso.uiuc.edu. Additional information is in an appendix in
the Eudora documentation, available from the same source. We have
successfully used this scheme with a direct modem connection to a
Unix POP server.

The second way is to learn a simple C-like programming language
which the SFU Eudora understands, and use it to get through the
maze of terminal servers and multiple logins. This version of
Eudora is available from fraser.sfu.ca.


The most popular dial-in connection schemes, however, employ
protocols developed specifically for that purpose, such as SLIP or
PPP. PPP software for the Macintosh is probably on drawing boards
or in beta tests, but I am not aware of any finished PPP products.
SLIP was recently made available on the Mac in the form of several
commercial offerings such as MacSLIP. A suitably configured SLIP
connection gives the dial-in Macintosh all the functionality of a
node attached directly to a TCP/IP network, even though it is of
course much slower.

For example, Alan Piszcz ([e-mail]) described his 9600 baud
dial-in setup as follows:

REMOTE SITE                        OFFICE
--------------------------------   ------------------------------
MAC II--MacTCP--MacSLIP--Telebit===Telebit--PC NFS--UNIX--SUN SPARC
Sys. 7   1.1     1.0      T2500     T2500  SLIP 4.0 TCP/IP  4.1.1


Last but definitely not least -- Patrick Hoepfner kindly allowed
me to include his introduction to the serial Internet protocols.
Here goes:


   SLIP or Serial Line Internet Protocol is a method of pushing IP
packets down a asynchronous (usually phone) line.  SLIP is a self
described "non-standard" that was developed on the back of an envelope
and implemented in 1/2 a day.  SLIP simply sticks a single character in
front of the IP packet.  Because you have binary IP packets over this
connection, this has to be an 8-bit clean connection.  You have to have
both modems using 8-bit, no parity, and no software flow control.
Because of this, many may not want to invest in software to do this if
your organization doesn't have modems that will support this.

   SLIP requires that the Mac SLIP its IP packets.  VersaTerm, MacSLIP,
and InterCon supply SLIP software.  The only difference (other than
cost) is that VersaTerm SLIP and MacSLIP will work with any MacTCP
software.  InterCon uses its own proprietary TCP/IP driver and
consequently it will SLIP only its own tools that use its TCP/IP
drivers.  But then again, InterCon can supply most all of the tools that
you need.  Since all of the SLIP products for the Mac are commercial
products, you should refer to their documentation for information on
setting it up on your Mac.

   For a successful SLIP connection you have to have a machine that will
host the SLIP connection.  That can be a unix machine, a VMS machine, or
even a terminal server.  There are public domain versions of SLIP for
unix machines that are available, check your local archie server for
more information.  If you have a Vax running VMS and you have a TCP/IP
package installed on it, chances are good that it too will host a SLIP
connection.  (See your local system administrator for more information.)
And if you have a terminal server, chances are good that it too will
support a SLIP connection (but not a CSLIP connection--see below for
CSLIP information and see the terminal server's administrator for more
details.)

   CSLIP or Compressed SLIP compresses the TCP/IP headers that are sent
with each packet.  The header are much the same each time and when using
CSLIP, each machine keeps a copy of the last header and only transmits
the differences between the last one and the current one.  This can make
the difference between a 4-5 byte header and the standard 40 byte
header.

   PPP or Point to Point Protocol is kind of like SLIP done right.
Among other wondrous things that PPP can do is to send not just IP
packets, but it is able to accept other types of protocols... Maybe we
will see AppleTalk over PPP.  Maybe with the next release of AppleTalk
Remote Access and MacTCP???  Maybe the version after that...

   How come I know so much about SLIP, CSLIP, and PPP?  Other that
being a genius and terribly handsome (and somethimes able to
spell).  I was pointed to two documents at "ftp.uu.net" in the
"vendor/MorningStar/papers" directory.  These unix compressed
PostScript files are named "sug91-cheapIP.ps.Z" and "ppp-white-
paper.ps.Z".