MacTCP and related Macintosh software

revision 1.4.2, December 1, 1995
Copyright Eric Behr, Northern Illinois University, Mathematics Department (behr@math.niu.edu)
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: 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).

The newest release of these notes can be obtained by anonymous ftp to ftp.math.niu.edu (in the directory /pub/mac/doc), or as http://www.math.niu.edu/~behr/Comp/mactcp.html. The older URL http://www.math.niu.edu/~behr/docs/mactcp.html will still work for quite a while but should be avoided. The HTML version is usually updated first and may be more accurate.
Please send all comments and suggestions to behr@math.niu.edu.

If you want to make me and my family happy, please send a postcard to

Eric Behr
NIU, Math, WH 320
DeKalb, IL 60115
Thank you!
This page has been accessed 192,778 times (and I only got 109 postcards so far... )
Note [11/17/97] This document will not be regularly updated in the foreseeable future. MacTCP is gradually being displaced by Open Transport, a much more mature and user-friendly product. There are several detailed Web resources devoted to it. If you want to learn a little about Mac networking in general, you may still want to read Appendix B, but if you have specific questions about Open Transport, please visit the Open Transport Q & A site and Mark Sproul's extensive compilation of OT information. Thanks to all who have visited this page!

CONTENTS

PREFACE
I. Generalities
II. MacTCP
III. Installation
IV. Configuration
V. Applications
VI. Sources
Appendix A. FTP primer
Appendix B. Elements of Macintosh networking
Appendix C. Dial-in access
Appendix D. MacTCP error codes
Appendix E. Open Transport - first look

PREFACE

In the past few years the Internet, once an obscure tool used primarily by academicians, has become a household word. This surge in popularity created great demand for information about software used to connect to the "Net", and to navigate its vast expanse.

Macintosh users are blessed with a cornucopia of excellent and innovative software packages for use with the Internet. Nearly all of them use the MacTCP driver from Apple.

I've spent many hours installing MacTCP on various Macs. 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. Moreover, in recent months I have been involved with Macs much less than I used to, so some of my advice is second-hand.

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.

back to table of contents

I. Generalities

I.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:

I.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 system 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.

Essentially all network software packages available for the Mac use the "MacTCP driver" from Apple. Despite its flaws, it provides a uniform interface to the low-level networking mechanisms, which in the long run makes life much easier for software developers and end users.

I.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: The first three methods are more reliable and provide higher speeds than the last one. However, modem connections are becoming more and more popular.

Macs on Ethernet can usually connect to the outside TCP/IP world without a problem; for a long time TCP/IP has been the protocol of choice on Ethernet networks. From the hardware point of view, all that is required here is an internal Ethernet card, an external SCSI Ethernet adapter, or -- for Macs with built-in ethernet -- a transceiver with a connector suitable for your flavor of Ethernet: coax, 10Base-T, or thick.

If you aren't sure which gadget to order, look at the network cables used throughout your site. Black TV-style cables mean that you need a coax, or 10Base-2 adapter. Thinner cables with modular plugs (like telephone ones, only a bit larger) indicate an "unshielded twisted pair", i.e. 10Base-T installation. Finally, if all you see is a (usually yellow) cable the thickness of a finger, you may need a special AUI drop cable which can be plugged into your adapter, and a thick Ethernet "vampire tap" which needs to be attached to the cable in a specific spot. In this last case, ask around -- don't do it yourself. Functionally all three types are identical, and they have nothing to do with the way MacTCP works.

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. For small networks simpler and cheaper devices or software such as microBridge/TCP or SuperBridge/TCP from Sonic Systems can be used, even though they are not full-fledged LocalTalk-to-Ethernet routers.

There are reports of exotic solutions consisting of a PC running public domain software (PCRoute), with an old Sitka TOPS card, successfully acting as an IP gateway for a LocalTalk network, but we have not tried them.

The Apple Internet Router, which is a software package running on a Mac connected to a LocalTalk and Ethernet networks, can provide TCP/IP routing between them with the optional IP Gateway module from Apple.

Macs connected directly to Token Ring can speak TCP/IP provided that the MacTCP Token Ring Extension from Apple is installed along with the main MacTCP driver.

Software routing of TCP/IP between LocalTalk and Token Ring is now reportedly possible with products from VICOM. Please note that this is second-hand information. The PCRoute solution mentioned above might also be worth exploring here.

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.

back to table of contents

II. MacTCP

II.1. What is it?

For the user, it is a hybrid of a Control Panel and a System Extension; it is configured just as the Monitors or Sound panels are. 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.

A companion product, AdminTCP, is another Control Panel which lets you lock certain parameters of MacTCP in place after they have been set. Its function is to help administrators prevent users from fooling around with previously entered settings. An average person will not need AdminTCP (you can get it only by purchasing the full MacTCP kit). It is also possible that your old AdminTCP (version 1.x) will work with MacTCP 2.0.x, but that has not been extensively tested and may have dire consequences.

II.2. How to get it?

MacTCP (version 2.0.6 as of this writing) is marketed by APDA (800 282 2732). Some time ago Apple renamed the entire package "TCP Connection for the Macintosh", which can make it easy for dealers to confuse it with a commercial product from Intercon Systems, TCP/Connect. We will continue using the generic name "MacTCP".

There are several ways of obtaining MacTCP:

The last two methods are probably most cost-effective; the only drwaback is that you don't get the less-than-helpful manual, and a few extra files (which most users won't need anyway).

If you want to inquire about terms of a site license, send e-mail to sw.license@applelink.apple.com.

You might still find a copy of MacTCP floating around the Net, because a few public domain packages used to include the driver. Beware: those copies are usually old (e.g. MacTCP 1.1.1), and according to the terms of the license Apple grants developers, such copies are supposed to be used only with the application that included them. They are not likely to work well with newer system software and CPUs, so even if you find one you may be in for a lot of hassle.

The new implementation of the Mac networking interface, Open Transport, is currently shipping with some models. For more information about it, see Appendix E.

II.3. Do I have the newest version?

Even though in some cases you might be able to get away with older revisions of the software, it is a good idea to get the newest one. Currently shipping System Software 7.5 includes a copy of MacTCP 2.0.6, buried among the PowerTalk support files. Even if you don't install 7.5 (or PowerTalk), you can use this driver with earlier releases of the System. The most widely distributed versions seem to be 2.0.2 and 2.0.4, which were included with some of the very popular books.

Versions 2.0.2 and 2.0.4 should be patched to 2.0.6 with updaters distributed on on-line services by Apple (see Part VI for more information). The updaters only work on original copies of MacTCP. If you do not have the "virgin" copy, it is possible to modify the installed one so the updaters will work, but anything involving ResEdit could be tricky -- do it at your own risk: disable the system heap bit of the .ipp DRVR resource in the copy you are patching.

back to table of contents

III. Installation

9 times out of 10 MacTCP can be installed simply by copying the relevant pieces into the System Folder and then configuring them. Still, non-standard extensions, or corrupted system software might make this task much more difficult.

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 some suspect proprietary network drivers installed on it. What's worse, some network applications seem to corrupt the System, and/or other important files, when they crash.

We shall leave those doomsday scenarios for later. In most cases the following procedure will work. Here we go:

back to table of contents

IV. Configuration

IV.1. Variables

The following questions are crucial to the proper configuration of MacTCP. Try to find the answers to all of them before you begin. Don't worry if the above sounds like black magic. Most of these questions can be answered by talking to your network administrator. Or you may have received this information from the Internet service provider when you bought dial-up access service. In some cases you won't need all the answers right away.

IV.2. Let's do it!

You should now be ready to configure MacTCP. Open the MacTCP control panel. You should see a window with one or more icons in the top part, and a button "More..." in the bottom.

IV.3. What can go wrong?

If things aren't working right away, you should concentrate on the following possibilities: If you are on a network, the best way to check the connection is to make sure the Mac can see AppleTalk devices such as printers and AppleShare file servers. Go to the Chooser and enable AppleTalk (you may have to reboot after that). Then open the "Network" Control Panel and select the same physical connection as the one MacTCP is using (LocalTalk, Ethernet, etc.) Finally, go to the Chooser again and check whether your local printers and file servers show up. If they do, you will at least know that the wires are OK.

In case of a dial-up connection, you should obviously look at the modem lights (the "off hook", "receive data" and "transmit data" indicators). Most serial drivers such as MacPPP also have an icon or some other indicator showing whether the driver thinks the connection is active, but this isn't always reliable. You may have to resort to diagnosing the modem connection with a serial line "sniffer".

Your network or serial drivers may be corrupted, or misconfigured; it may be necessary to reinstall them from scratch. You may also be using an incorrect modem init string; Adam Engst's guide on troubleshooting such problems can be obtain by mailing a request to tisk-faq@tidbits.com.

You can use the MacTCP version of NCSA Telnet to open a connection to a major site such as rs.internic.net.If Telnet attempts to open a connection, but nothing happens, you should look at the "Connections" menu. If it says "XXX is being looked up", chances are that MacTCP isn't getting responses from the nameservers you gave it. You should try connecting to a numeric Internet address, e.g. 198.41.0.5.

If Telnet says "XXX is being opened", your Mac may not have the correct "default gateway" information. Open the MacTCP inner panel and check whether the 0.0.0.0 gateway setting has changed to something else. If it didn't, you will have to get the gateway address from the administrator and enter it manually. If you know the address of a host on your local network, you can try opening a connection to it; this should succeed even if the default gateway isn't set properly.

If your application gives a MacTCP "out of memory" error, you may be running into a problem caused by the interaction between older versions of MacTCP and a certain new implementations of Unix nameservers. The problem should be fixed by upgrading to MacTCP 2.0.6.

It may be that some other computer is using your manually assigned IP address. When MacTCP loads, it in effect says: "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 well. 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 "Error opening TCP drivers - possibly no dynamic addressing". Talk to the local administrator to verify that the address you were given is not used by anyone else.

Different applications translate MacTCP error codes into different messages. Some just display the error number, which isn't very helpful. See Appendix D for a partial list of those codes, gleaned from the MacTCP Developer's Kit distributed by Apple.

Much of the above can be diagnosed with a utility MacTCP Watcher, written by Peter Lewis, and available from most Mac archives.

back to table of contents

IV.4. Drastic measures

If you are still having problems, trash the following from the hard disk: MacTCP, AdminTCP, MacTCP Prep, and MacTCP DNR. These files are found in the System Folder proper (in pre-7 Systems) or in various subfolders, such as Control Panels, Preferences and Extensions. Reboot and install fresh network drivers, then install MacTCP and configure it carefully again. Reboot one more time and see if all this helped. If problems persist, consider trashing not only the MacTCP files, but also the System, Finder, all network drivers and control panels (AppleTalk, EtherTalk, Network), and reinstalling fresh copies. This is almost certainly an overkill, but in some cases it is also a recipe for instant happiness. 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.

Disable all system extensions and non-essential network-related Control Panels, 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, system extensions can 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.

Remember that in case of a dial-up connection, your Mac is only one piece of the puzzle. The other end, i.e. your provider's modems, routers etc. also have to be properly configured, which might not be the case. Moreover, the provider may be unwilling to admit that something is wrong -- it's been known to happen. You may have to switch to another one. Shop around, and stick to the reputable Internet businesses.

If these radical surgeries still don't work, donate your Mac to a local school, get another one, and begin life afresh.

IV.5. Tricks, hints, and caveats

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. For the ping to succeed you must first start up some Internet application on the Mac.

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 back into 12 hex digits to get the real hardware address.

Older Macs, notably the Plus, become overworked while running System 7 (more precisely, the newest versions of AppleTalk) and MacTCP 1.1. Make sure to install a new version of MacTCP.

Sometimes the physical link icons (usually the "LocalTalk built-in" icon) mysteriously disappear from the old versions of the MacTCP control panel. Make sure you are using a current MacTCP.

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!

IV.6. Using AdminTCP

If you are responsible for configuring MacTCP in your department or organization, in some cases you will want to lock the settings you have entered, so that users with itchy hands will not fool around with them.

Open the AdminTCP panel (even an old version should work with a new MacTCP, but of course it is best to get a current one!) In the inner panel click the three checkboxes which lock the address, and click the "Protected" box. Close the panel and reboot right away.

Remember to trash AdminTCP from the user's disk afterwards, so he won't be able to unlock the settings, unless you trust the user not to mess things up intentionally.

If the prospective user is a TCP/IP sage, you should 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!

IV.7. More about 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, explaining what went on when we filled in the MacTCP "Nameserver information" fields. The Domain Name System is used by computers to convert the human-friendly names such as "rs.internic.net" to numeric addresses (IP numbers) such as 198.41.0.5. Internet computers also use this system to "reverse-map" numeric addresses, i.e. to verify that your numeric address does correspond to a name which is recognized by the DNS. A part of MacTCP, the "resolver", is responsible for doing all this on your Mac.

If your network is connected to the Internet, your computer lives in some well-defined "domain". In my case, it is math.niu.edu, and a machine with address 131.156.3.3 is providing name service for that domain. I thus enter "math.niu.edu" (do not use quotes) in the Domain field, and 131.156.3.3 in the Server field next to it. I also click the Default button. This informs MacTCP that my computer is in the math.niu.edu domain, so when I tell my Mac to telnet to "sunflower", it will query the nameserver about the address of "sunflower.math.niu.edu".

If the local nameserver doesn't keep a large table of addresses, or if it is less than reliable, you will probably want to add some backup servers (this is generally a good idea). In particular, one or more Domain fields could contain the period alone to handle the "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 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.

If the resolver is given a name without periods in it, e.g. "sunflower", it will tack on your default domain, and send out a query for "sunflower.math.niu.edu". If there is no computer by that name, the query will fail.

If the name contains periods, MacTCP considers it to be a "fully qualified domain name", and tries to match the tail of it with one of the domains you entered in the MacTCP panel. For instance, a query for "sunflower.math.niu.edu" will go to the nameserver specified for domain math.niu.edu (if any), then -- if that fails -- to the nameserver for niu.edu (if any), and finally to one of the servers for the root (.) domain.

There is currently no support for the so-called "partially qualified names"; e.g. "sunflower.math" will _not_ get anything tacked on, even though you may hope that MacTCP will be smart enough to try adding "niu.edu" to it.

A small text file called Hosts can be put in the System Folder proper; it lets you enter additional information which MacTCP uses when it carries out the name resolution process described above. For example,

clinch.math.niu.edu      IN   A   131.156.3.3
math.niu.edu             IN   NS  clinch.math.niu.edu
rs6000.cmp.ilstu.edu     IN   A   138.87.1.2
risc                     CNAME    rs6000.cmp.ilstu.edu
in the Hosts file tells MacTCP that clinch.math.niu.edu has address 131.156.3.3, that it is a nameserver for my domain, that rs6000.cmp.ilstu.edu has address 138.87.1.2; since I connect to it often, I want my Mac to use rs6000.cmp.ilstu.edu whenever I say "risc." (if there were no dot, MacTCP would start looking for rs6000.math.niu.edu!).

A Hosts file on a Mac tends to be neglected or overlooked, unlike -- say -- the NIS hosts file on your main network server. Keep this in mind when deciding whether to put a lot of information there. When IP addresses change, it may come back to haunt you, since you may not even remember it's there. It's better to rely on a reliable, properly configured and maintained nameserver for your domain.

A bug in MacTCP 2.0.4 discovered by Sylvia Elliott causes the resolver to fail on CNAMEs in the Hosts file which contain digits. MacTCP 2.0.6 may have fixed this.

The newest versions of the resolver also disallow host names which contain underscores. This has caused significant controversy; even though this is "correct" behavior according to Internet standards, older implementations have not enforced this restriction, and there are several computers out there with such names. Until they disappear you will have to use numeric addresses to reach them.

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.

IV.8. Minimal setup

It is often useful to construct a minimal network consisting of two Macs running TCP/IP: either to test an application being written, or just to see this side of Mac networking in action. Here is what you should do to get such a mini-net running.

Connect the Macs with a LocalTalk cable (PhoneNet boxes at each end recommended for good reasons, even though a simple printer cable will do for those who like risks). Ethernet-ready Macs can be connected with a short piece of coax cable (good terminators at each end!), or a twisted pair cable. Do not use a hub-to-adapter cable! it won't work. You have to swap the send/receive pairs as follows:

  RJ-45 plug pins
   1 -------- 3
   2 -------- 6
   3 -------- 1
   6 -------- 2
On each Mac put a file called Hosts in the System Folder; in each of them type:
testa     IN   A    244.244.244.1
testb     IN   A    244.244.244.2
Avoid using numbers in host names, i.e. don't try test1 or mac15. And remember that you have to get official IP addresses before you hook the Macs up to the outside world.

In MacTCP set the appropriate link icon (LocalTalk or Ethernet), addressing to manual, gateway to 0.0.0.0, and leave the nameserver information entirely blank.

In the "outer panel" set the IP address to 244.244.244.1 on one computer, and to 244.244.244.2 on the other one. Reopen the "inner" MacTCP panel and verify that subnet mask is 255.255.255.0, and that network class became C.

Enable AppleTalk in the Chooser, reboot, and you should be up and running. Install some clients and servers on the Macs (Fetch and FTPd, a Web client and httpd, and so on) and try them out.

Since MacTCP still has problems with various timing parameters, on a network like this where delays and transmission times are weird you may occasionally see errors such as "No connection in place".

As Leo Willems pointed out, a truly minimal configuration consists of a single Macintosh; for example, a developer may want to test a TCP/IP client application with a server program running on the same computer. Set TCP/IP to LocalTalk and manual addressing as above, and don't connect it to anything! Or, if you want to check Ethernet operation, plug in a self-terminating Ethernet transceiver and select the Ethernet icon in MacTCP.

back to table of contents

V. Applications

There are many commercial programs which use TCP/IP connectivity (InterCon Systems family of networking applications, VersaTerm from Synergy Software, MacX from Apple, just to name a few). I will not review them here because I have had little or no experience with them. Let the vendors speak for themselves.

The list of public domain or shareware software which follows is far from complete; moreover, new applications appear very often, and we cannot possibly keep it up to date. We will focus on a few most important packages which should get you started. See Part VI for information on obtaining this software.

V.1. Terminal emulation

There are currently two primary free 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 client and server, but support for this will disappear in future versions.

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, given the right software installed at the big iron end.

NCSA Telnet used to come in two versions: one which relied on MacTCP, and one which included built-in TCP/IP drivers. Starting with Telnet 2.5, the two have been merged into a single package.

You may also want to try a third package, Comet from Cornell University, which is still available from some ftp archives. It can be used over a network with MacTCP, or with an ordinary modem connection.

V.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, sometimes unreliable, and may be difficult to maintain.

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). Non-commercial versions are still maintained and supported by Steve, even though innovations and functional improvements find their way into the commercial package first.

Eudora and other similar clients (such as POPMail II from the University of Minnesota) 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 one of the encoding schemes, e.g. BinHex (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.

The current versions of Eudora also support MIME (Multi-purpose Internet Mail Extensions), a standard for transferring images, sounds, international characters etc. via the ASCII-oriented Internet e-mail.

Seting up a POP server on most Unix computers is rather trivial, but it does require superuser privileges. 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.

One of the selling points of the POP protocol is that several decent clients are also available for DOS and Windows computers (NuPOP, PC-Eudora from Qualcomm, etc.). Moreover, most of those clients can send and receive attachments using standard encoding; in many cases it is possible -- say -- to save a Word document as a WordPerfect DOS file on your Mac, attach it to a letter in Eudora, and send it to someone who is stuck with a WordPerfect Office mail system behind a Novell SMTP gateway...

In case you don't have a bigger 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. Glen Anderson's MailShare does just that, in addition to providing POP service for other Macs. If all you want is SMTP service for the individual Mac, you can try Lee Fyock's LeeMail, but MailShare is probably a better choice at this time. Naturally, a Mac configured as an independent Internet mail host had better have reliable connectivity with the world at large (and a properly configured Domain Name Resolver).

V.3. FTP

Just like Eudora seems to be the mail client of choice, Fetch by Jim Matthews reigns in the FTP area. Older clients include the HyperFTP stack, and the orphaned (but still useable) XferIt. There is also an FTP server that runs on Macs, FTPd by Peter Lewis. Anarchie is a very convenient marriage of an Archie client (which searches lists of software on anonymous FTP servers) with an FTP client.

As we will explain in Appendix A most Mac files you download will require further processing. Fetch allows you to do this painlessly if you install gadgets such as StuffIt Expander and MacGzip on your disk, and configure things so that incoming files are automatically decoded/decompressed by them.

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.niu.edu. The system administrator of your nameserver computer might be willing to enter your address in his database.

V.4. Network news

There are several Mac applications designed to let you access Usenet news: Newswatcher and Nuntius are probably the most popular. 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".

Reading Usenet articles usually involves downloading humongous lists of articles over a slow connection such as overloaded LocalTalk, or worse -- a modem link, 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.

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. As with FTP, this usually requires having a valid domain name, and the server must have been configured to accept uploads from your computer. Even though some servers allow free read access and only 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 then complain about "broken newsreaders".

V.5. Internet Gopher

The Internet Gopher is a system of "gopher servers" on various Internet hosts which can be contacted by a gopher client, passing the connection on to other servers in a way transparent to the user. The data on the servers are presented as menus, which can be text or binary files, links to ftp archives or Usenet news servers, or finally pointers to other gopher servers. It is a very convenient mechanism for putting the bewildering spectrum of Internet services under one roof. The principal Mac client, TurboGopher, has been created by the designers of the gopher system at the University of Minnesota. There is also a gopher server which runs on Macs.

Gopher has become one of the standard ways of providing access to distributed information such as campus directories, WAIS servers, on-line publications, etc. It is also the preferred method of accessing many of the anonymous ftp sites, such as the sumex archive at Stanford.

V.6. World-Wide Web

In the 70's FTP was "it". In the early 90's it was the gopher. In mid-90's, it's WWW, or "W-cubed", or World-Wide Web. Visionaries at the European CERN laboratory in Geneva realized that hypertext ideas (conceived quite a long time ago) could be combined with Internet connectivity to provide a uniform access to resources "out there".

The idea really took off when programmers at NCSA released Mosaic, a client application which allowed Unix machines, Macs, and PCs to access WWW servers in a way that showed the stunning capabilities of the system. After connecting to a WWW "page" you see text, links to other parts of the document, icons, images, links to other pages thousands of miles away; you can click on an icon and hear a sound; click on an underlined address and send a note to someone; click on an electronic newspaper's masthead and see the editor's face. Access to other protocols such as FTP or telnet connections is integrated into this paradigm.

The development of the Web has forced some other standards to evolve rapidly. The "uniform resource locators", or URLs, are the new language used to specify where a given item lives in the net universe: e.g. ftp://ftp.math.niu.edu/pub/mac/doc/mactcp.txt means "connect by FTP to the host ftp.math.niu.edu, and retrieve the file mactcp.txt in the directory /pub/mac/doc". Together with MIME, WWW has helped the evolution of standards for exchanging complex documents between different systems.

Documents written in the WWW HyperText Markup Language (HTMLs for short) are very flexible; they can be used to provide a help system for local users, a tutorial for novice photographers or origami fans, or a sound-enhanced catalog of music recordings. They are also quite "expensive" in terms of the network load: WWW pages tend to be full of images, sounds and icons comprised of hundreds of kilobytes of data, sometimes causing unprecedented congestion on info-ways we all use. Let us hope that this will soon cause an equally dramatic increase in the bandwidth of the Internet infrastructure.

Two Mac clients dominate the field: NCSA Mosaic, and Netscape from Netscape Communications Corporation. Netscape is a commercial product: please make sure you read the accompanying license. A third, MacWeb, is also gaining popularity. You can turn your Mac into a WWW server with a Mac HTTP daemon application (e.g. httpd or MacHTTP), available from many archives.

V.7. Miscellaneous gadgets

Many people need to switch between several MacTCP configurations (e.g. when using a PowerBook at home with PPP and at work with a direct network link). John Norstad's MacTCP Switcher is a great help in such situations (note that OpenTransport has the built-in capability to store various configurations and switch between them without rebooting the computer).

Even if you install only the basic Internet programs, you will notice that configuring them all is quite a balancing act. At the same time, many of them share certain parameters: your name, address of a mail server, preferred e-mail address, and so on. The program InternetConfig has been created to help you organize such parameters in one place.

Older versions of these notes listed a number of specialized Mac applications which use MacTCP in this section. Since this category is so fluid, with some programs being abandoned, and new ones showing up, I feel it would be unfair to single out just a few packages I like.

Instead, I will single out one person: Peter Lewis, who has been busy creating useful MacTCP applications for some time now. They include an FTP server, a MacTCP debugging application, an intelligent "archie" client for searching and accessing FTP archives, a "talk" program, and so on. I feel that Peter's work, which has helped many of us enormously, deserves special recognition and support.

back to table of contents

VI. Sources

There are some excellent sources of background information on the Internet in general, and TCP/IP in particular. Two classics which come to mind are:

"Zen and the Art of Internet" (by Brendan Kehoe),
"Hitchhiker's Guide to the Internet" (by Ed Krol).

Both can be obtained by anonymous FTP from ftp.uu.net (directory /inet/doc). The files are Unix-compressed, so they should be downloaded using binary mode and then decoded with a Unix-style uncompress application. See Appendix A for a primer on ftp. Note that newer editions of "Zen" are only available commercially.

Several FTP sites have copies of most newer Requests For Comments (RFCs), documents which establish Internet standards. Try rs.internic.net or nic.switch.ch. To get started download the files rfc-index and fyi-index. There is no substitute for reading RFCs (painful as it may be...)

A popular and very complete paper reference is "The Whole Internet User's Guide and Catalog", also by Ed Krol, published by O'Reilly and Associates.

A three-volume series "Internetworking with TCP/IP" by Douglas Comer is published by Prentice Hall, and contains everything you have ever wanted to know about the protocol that makes the Net tick.

Frequently Asked Questions (FAQ) files are the accepted method of answering "newbie" questions; even if you consider yourself an experienced 'Netter, you may want to check them out. The most relevant one is available by FTP from rtfm.mit.edu, in the directory /pub/usenet-by-hierarchy/comp/sys/mac/comm.

The main archive of public domain and shareware Mac software is on sumex.stanford.edu. There are several "mirrors" which you may want to try when sumex is too busy to let you in, e.g. nic.switch.ch or src.doc.ic.ac.uk, but they are often just as busy as sumex. Another fairly complete Mac archive is on mac.archive.umich.edu.

Adam Engst keeps a comprehensive collection of Mac communications software on ftp.tidbits.com, in the directories /pub/tidbits/tisk and /pub/tidbits/select. For announcements of new versions of this software, WWW users should see http://www.tidbits.com/iskm/. If you are looking for a communications package, or an init string for your modem, or a SLIP dialup script, those are the places to look. You can also send mail to iskm@tidbits.com to inquire about the current status of his "Internet Starter Kit" book.

Official MacTCP-related files released by Apple can be obtained by anonymous ftp from ftp.info.apple.com and from seeding.apple.com; Web fans can try http://www.info.apple.com.

Note that Apple likes to distribute some of its software as "disk image" files. Such files have to be loaded into an application such as DiskCopy (available on ftp.info.apple.com in /dts/utils) or ShrinkWrap, which can then produce exact copies of an original master floppy disk. Moreover, many files on Apple archives are prefixed with the lengthy lawyer-speak section, which can justifiably confuse some BinHex decoders; after downloading such .hqx files, use an editor to cut out the legalese before de-BinHexing.

Here are pointers to software which is found in less obvious places:

Eudora: ftp.qualcomm.com
GopherApp: ftp.bio.indiana.edu in /util/gopher/gopherapp
MacDump: bbn.com in /pub/MacDump
NetNews: ftp.bio.indiana.edu in /util/mac
Netscape: ftp.mcom.com
POP servers: ftp.qualcomm.com, ftp.cc.berkeley.edu
tn3270: brownvm.brown.edu
TurboGopher: boombox.micro.umn.edu in /pub/gopher
VMS POP server: ftp.indiana.edu in pub/vms/iupop3

This should keep you busy for now...

back to table of contents

Appendix A. An FTP Primer

A.1. Downloading text files

Use any account available to you on a well-connected host. Type "ftp ftp.math.niu.edu". When asked for a username, reply "anonymous"; give your mail address as password. In 9 cases out of 10, archives such as this one will accept "ftp" in place of "anonymous", which is meant as a favor to the new spelling-challenged generation. 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 /pub/mac/doc", 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 /pub/mac/doc directory on ftp.math.niu.edu:

help/accessing-files.txt
report/how-do-i-find.txt

Many more such files are on sumex.stanford.edu, in the directory /info-mac/comm/info (most of them are mirrored on ftp.tidbits.com in /pub/tidbits/tisk/info). See Part VI for details.

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.acns.nwu.edu, in directory /pub/disinfectant; it can also be found in many other places, e.g. on sumex.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 information about newly discovered viruses.

A.2. 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 a utility which can not only transfer files, but also un-BinHex them -- such as Fetch, or TurboGopher. You can then tell it to connect directly to, say, sumex, dowload the interesting BinHex'ed files, and decode them while they arrive.

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 mentioned in Part VI.

A.3. What next?

When you have learned how to download Macintosh executable files, it's time to go hunting for specific applications. Use the hints given above to "bootstrap" yourself. The possibilities under your fingertips are something that your parents didn't even dream about.

You may want to start experimenting with Gopher, and WWW at this point. Most software available via FTP can also be downloaded using those tools, which often let you find things more quickly and easily. We have already mentioned another application, Anarchie, which is invaluable in locating hard-to-find files on FTP servers.

A.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!

back to table of contents

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 document, 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 reached their maturity 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, Token Ring selected in MacTCP. All is peachy. A TCP/IP-aware application on the Mac (such as NCSA Telnet, etc. -- see Part V) wants to communicate with a Cray at the Space Station "Alpha", which by the time I finish this might 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...

back to table of contents

Appendix C. Dial-in access

C.1. ARA

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 or faster connection provides 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 similar, you can't use ARA for TCP/IP access to the network.

C.2. SLIP and PPP

The most popular dial-in connection schemes, however, employ protocols developed specifically for that purpose, such as SLIP or PPP. A public domain MacPPP driver is available from several Mac archives, and is quite serviceable. There are also commercial PPP drivers. SLIP is available on the Mac in the form of several commercial offerings. More information on SLIP software can be found on ftp.bio.indiana.edu in the directory /util/slip. Pat Hoepfner also suggests reading 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".

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 usually much slower, even with the modern 28,800 bps modems. Configuring reliable dial-up connection is not a trivial matter, because the modem and the SLIP or PPP software add a new layer of complexity. One universal rule seems to be that with fast modems you have to: (a) use a "hardware handshaking" modem cable; (b) set your software so it uses hardware (CTS or RTS & CTS) handshaking; and (c) initialize the modem so it has XON/XOFF handshaking disabled.

In most cases you will set MacTCP to server addressing when using serial line connections (unless your provider only supports static address assignment). Most of the MacTCP parameters (gateway, subnet mask, etc.) are either irrelevant here, or will be set by the SLIP or PPP driver at connection time.

Let's now look at two most popular serial IP drivers for the Mac: MacPPP and InterSLIP. They are both freely accessible from on-line sources. I don't know much about modems, and I use SLIP and PPP only occasionally, so the sections that follow are not likely to help you troubleshoot difficult problems. Adam Engst's book mentioned in Part II has much more information on the subject. You can also receive some help by sending an e-mail note to tisk-faq@tidbits.com.

If you are having problems with sending longer messages via Eudora over a dial-up connection, you may want to fill out a report to help track down the cause.

C.3. InterSlip

Start up InterSLIP Setup. Create a new setup using the File menu. Double-click on it to open it. Set the modem parameters, remember about hardware handshaking. Opening InterSLIP Setup will have created a folder InterSLIP Folder:Gateway Scripts inside the Preferences Folder in the System Folder. Create your connection script, which is a text file (see simple example below), and put it in that folder. You should now be able to select that file in the Gateway setting in InterSLIP Setup.

You can now set other parameters. I have the nameserver entered manually in InterSLIP, RFC compression on, hardware handshake, Hayes-Compatible modem (I use an AT&T Dataport 14.4). IP address and MTU Size are empty; they will be obtained from the SLIP server at connection time. Username and password will have to be set to values you were given by the SLIP administrators, or left blank if the server does not require them.

Here is a simple connection script which should work with a server that doesn't do user authentication. Most real-life situations will call for a more complex one.

!
@originate
note "Waiting for prompt"
matchclr
! edit this to match the prompt your server gives
matchstr 1 4 "TSERVER>"
matchread 50
note "Gateway not responding!"
exit -1
!
@label 99
pause 1
sound
pause 60
exit -1
!
@label 4
note "Requesting SLIP"
write "slip\13"
matchstr 1 5 "Entering SLIP mode."
matchread 120
note "Cannot invoke SLIP mode"
jump 99
!
@label 5
matchexp 1 6
"[0-9][0-9]*\\.[0-9][0-9]*\\.[0-9][0-9]*\\.[0-9][0-9]*\\."
matchread 120
note "No IP address given"
jump 99
!
@label 6
setip "^0"
matchclr
matchexp 1 7 "[0-9][0-9]*"
matchread 120
note "No MTU value"
jump 99
!
@label 7
setmtu "^0"
exit 0

C.4. MacPPP

If you have access to a PPP server, you may want to try the freely available MacPPP driver from Merit and University of Michigan. It is available on most Mac archives, e.g. on ftp.tidbits.com in /pub/tidbits/tisk/tcp. Rather complete documentation available from the same sources. As with InterSLIP, it is crucial to get the handshaking settings straight.

Instead of a script, MacPPP uses a set of edit fields in which you enter the strings to wait for, and responses to send in order to negotiate connection parameters. In the simplest scenario you would simply tell MacPPP to wait for your server's prompt, and then send a command requesting PPP mode. It is easy to make a mistake here, forget to end the response with a carriage return, etc.

To see what your server sends during connection attempts, and to experiment with the responses it may expect, you can simply dial into it using a plain-vanilla terminal emulation package, e.g. ZTerm, and jot down what happens on the screen.

Even though MacPPP can be set to close the connection after a specified period of inactivity, it will perform only a "soft close", and will later periodically try to reestablish it. This can dramatically alter your next phone bill... Remember to use the "Hard Close" button to terminate a PPP session.

C.5. Multiple Macs with dialup

One of the most frequently asked questions comes from users who have purchased a SLIP or PPP account from their service provider, but would want a small home or business network to take advantage of that single Internet entry point.

After the Mac connected to the modem establishes a serial line link, one would need to connect the other computers to its network port (LocalTalk or Ethernet), and have MacTCP route packets between the two ports on an "as-needed" basis. This is non-trivial, and can only be accomplished with special software.

One possibility which has existed for quite some time is to use a Unix variant which runs on a Mac and has this capability -- e.g. Mach from Tenon Intersystems, which runs on virtually any Mac and allows such routing. Another possibility is to use a PC running Linux, which can also be configured to provide the routing function. This, however, means getting involved in Unix administration, which is not for the faint of heart.

A better alternative might be the recently released family of software routers for the Mac from VICOM. Some of them can apparently be used for the purpose described above. Note that I have not tried any of them, and that there might be competing products that I'm not aware of.

back to table of contents

Appendix D. MacTCP error codes

Please note: the information in this section is in no way blessed or authorized by Apple Computer, Inc. It is simply a summary of information contained in publicly available header files related to MacTCP (those are Copyright: (C) 1984-1994 by Apple Computer, Inc.) The list is not necessarily accurate nor up to date.
-23000    bad network configuration 
-23001    bad IP configuration error 
-23002    missing IP or LAP configuration error 
-23003    error in MacTCP load 
-23004    error in getting address 
-23005    connection is closing 
-23006    invalid length (of what??) 
-23007    request conflicts with existing connection 
-23008    connection does not exist 
-23009    insufficient resources to perform request 
-23010    invalid stream pointer 
-23011    stream already open 
-23012    connectionTerminated 
-23013    invalidBufPtr 
-23014    invalidRDS 
-23014    invalidWDS 
-23015    openFailed 
-23016    commandTimeout 
-23017    duplicateSocket 

-23032    Packet too large to send w/o fragmenting 
-23033    destination not responding 
-23035    ICMP echo timed-out 
-23036    no memory to send fragmented pkt 
-23037    can't route packet off-net 

-23041    nameSyntaxErr 
-23042    cacheFault *
-23043    noResultProc 
-23044    noNameServer 
-23045    authNameErr 
-23046    noAnsErr 
-23047    dnrErr 
-23048    outOfMemory 

back to table of contents

Appendix E. Open Transport - first look

Apple's new implementation of the networking interface, Open Transport, is scheduled to become an integral part of the next major version of the operating system ("Copland"). Early versions are currently included in System 7.5 being shipped with the models which use the PCI bus. Open Transport is an "umbrella" which integrates the various protocols a Mac can use to communicate with other network devices. It now includes AppleTalk and TCP/IP, with support for others (serial protocols, Novell IPX) to be added in the near future.

At this time we can only offer a cursory description of the current release. The software is still under active development, so some of our observations may not apply to future versions.

E.1. Do I need it?

Most likely not, if you have MacTCP up and running. At this time the only "official" way to get Open Transport is to buy a PCI-based Mac, or to obtain a copy through Apple's beta testing or early evaluation program. OT is not supposed to be installed on computers which do not require it. However, we took the risk of putting it on an SE/30 running System 7.0.1, and on a PowerBook 520 under 7.5, both with a direct Ethernet connection.

Even though in my case there were no apparent problems, and the new features are certainly tempting, you have to think twice before trying OT on your Mac: there have been many reports of serious trouble, in particular with serial drivers such as MacSLIP.

E.2. New features

Open Transport TCP/IP implementation is more modern than the old MacTCP code. The four main differences that should be apparent to an average user are: cleaner user interface; performance improvements; the ability to specify several domains to search; and the ability to switch between configurations without restarting the computer. In the next section you will see statements such as: press the "Select Hosts File" to select the Hosts file"... This is the best illustration of the fact that the interface has improved quite a bit. It is almost self-explanatory, with various fields and menus doing precisely what the labels say they should be doing. What a relief!

E.3. Installation and configuration

The OT Installer adds several control panels and extensions. Before running it, back up MacTCP and AdminTCP, and make sure you have a floppy from which you can reinstall the Network control panel and extension if necessary.

The two new control panels, AppleTalk and TCP/IP, are roughly the equivalents of the old Network and MacTCP panels. We will concentrate on TCP/IP only.

Open the TCP/IP panel. The Edit menu contains an item "User Modes..." which determines the amount of detail you are shown: Basic, Advanced, and Administration (the equivalent of AdminTCP). The last one lets you set a password needed to get into that mode. For now, select Advanced.

The first pop-up menu, labeled "Connect via:", contains the choices "Ethernet" and "AppleTalk (MacIP)". The latter should be used when you need to encapsulate TCP/IP packets in AppleTalk, as mentioned in Appendix B. More choices will show up if you have other network drivers installed (Token Ring, MacPPP, etc.)

In the next pop-up menu you select the configuration method. In addition to "Manual", in case of Ethernet or a serial link there are three other choices: BootP, RARP, and DHCP. All three require some sort of server from which the Mac will obtain its TCP/IP settings. Apple documents mention that selected serial drivers (MacSLIP, InterSLIP, MacPPP) have been tested with BootP, which is roughly equivalent to the old "Server" setting in MacTCP. They also indicate, however, that when using a PPP server which will provide an Internet address for the Mac, "Manual" configuration should be used; the PPP server will then overwrite the IP address entered below. We have not had a chance to try Open Transport with any serial protocol yet.

DHCP is a versatile, standard method of administering settings for a large number of hosts. This is the method of choice for network managers who are tired of chasing down address conflicts and other problems. DHCP servers run under most mainstream flavors of Unix, under Windows NT, and so on.

When the connection is to be made via AppleTalk, one of the configuration methods that shows up is "MacIP server"; this requires a gateway (such as an Ethernet/LocalTalk router) which will assign an IP address to the Mac.

The "Select Hosts File..." button lets you point OT towards a file containing addresses and aliases of hosts, but this is discouraged as a potential source of problems in administering many computers. It's better to rely on nameservers, especially since the Hosts file has been traditionally used to circumvent shortcomings in the MacTCP name resolver -- and those have largely been removed in the Open Transport implementation.

To finish manual installation you need the same information as indicated in Part IV. Enter the numeric Internet address of the Mac in the "IP Address:" edit field. The default domain (e.g. math.niu.edu) goes in the "Domain name:" field. Decimal value of the subnet mask (e.g. 255.255.255.0) should be entered in the next field.

The "Router address:" field can contain numeric addresses of one or more routers which connect the local network to the rest of the world. The software will detect failures in contacting any one of them, and try the next one, etc. Similarly, the "Name server addr:" field should contain at least one numeric address of a reliable local nameserver.

One of the shortcomings of MacTCP had to do with so-called "partially qualified domain names". Suppose I tell the resolver to figure out the address of a host "mvs"; the old algorithm would see that there are no periods in it, and would query the nameservers for "mvs.math.niu.edu". However, there is no such computer. Or if I wanted to contact a host in another department, and typed simply "mp.cs", MacTCP would send a query for "mp.cs.math.niu.edu", failing again. A better approach is to strip away parts of the domain, checking for "mvs.niu.edu" and "mvs.edu" (or "mp.cs.niu.edu", and "mp.cs.edu") as well. In either case the second try would succeed.

OT's Domain Name Resolver provides this convenience as follows. The "Admin domain:" field should contain the fragment of your domain which you want to append to names if the first query fails. If I enter "niu.edu" there, both examples given above will work as expected. In addition, you can specify other domains in the "Search domain names:" field to extend this mechanism; for example, putting "cs.niu.edu" in it would let me type simply "mp" to get to "mp.cs.niu.edu". This, of course, assuming that there is no "mp.math.niu.edu" or "mp.niu.edu" (otherwise they would be found first).

Finally, many configurations can be saved and loaded through the "File" menu. You can switch between them without restarting, or edit the default one (although there is a timeout period of about 2 minutes during which OT keeps the old settings in its cache).

E.4. Final comments

On a 68xxx Mac, with an application which isn't explicitly written for OT, there are no direct performance improvements over MacTCP. A 2+ MB file transferred with Fetch 2.1.2 from a SparcStation 5 to a PowerBook 520 over a lightly loaded Ethernet produced almost identical average rate of about 85 kbps with both drivers. The speed advantages, if any, will be seen on a PowerMac with an application using the Open Transport function calls, because those are native, and would not have to be trapped by the MacTCP backwards compatibility mechanism present in OT.

However, in my view the new software appears to be much more robust. In one particular reproducible situation a telnet session to a nearby Unix host "stutters" and temporarily hangs with MacTCP; the same setup works like a charm with OT.

I have been using OT on two Macs for about a month with no problems whatsoever. But keep in mind that both use a direct Ethernet connection, and both are relatively "clean" (very few non-standard extensions and gadgets).

One notable omission in the TCP/IP component is that it doesn't seem to use routing information packets. As we mentioned in Part IV, entering 0.0.0.0 in the "default gateway" field of MacTCP makes it listen to the network and (usually) discover an appropriate router. My copy of OT would not do that, whether I entered zeroes in the "Router address" field or left it blank. Another quirk is that the "Info" button is supposed to display the software version and the computer's Ethernet address, and mine did not show the latter.

I also had a problem with the "Use 802.3" button, which is meant to make the Mac use an Ethernet standard sanctioned by the IEEE committee, as opposed to the more traditional "blue book" standard developed by 3Com. One of my Macs would happily work with that setting, while the other one didn't. This may have been caused by an Ethernet card incompatible with 802.3.

Finally, Open Transport is a memory hog. On the PowerBook with System 7.5 the shared libraries which OT uses take up a lot of RAM, even before any TCP/IP application starts up; after it does, the System takes up over a megabyte of RAM more than it does when MacTCP is loaded. This difference might be less pronounced with the native PowerPC libraries, but I haven't tried this.


back to table of contents