SPONSORED LINKS
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 BehrThank you!
NIU, Math, WH 320
DeKalb, IL 60115
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
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
Please follow this simple advice:
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.
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
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.
There are several ways of obtaining MacTCP:
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.
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:
Let me reiterate that the physical link setting has little 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.
Newer system software may refuse to load the low-level networking support at boot time if AppleTalk is disabled, preventing the Mac from talking to the network adapter. It's safer to keep AppleTalk turned on, especially when using built-in Ethernet in the newer Macs. This is also always the case if you are using TCP/IP through the LocalTalk port: you must have activated AppleTalk in the Chooser -- otherwise that port is simply dead, and MacTCP doesn't know how to communicate with the outside world at all.
Here are a few rules-of-thumb for choosing the physical layer:
In what follows I will use some examples which are real addresses of real computers on my network; please don't just copy them -- make sure to change them to ones that are appropriate for your setup!
If you were given additional nameserver addresses, or if you wish to use a backup nameserver for your domain, enter that information in the rows below. The net result should be something like this:
-------------------------------------
| math.niu.edu | 131.156.3.3 | x | ("default" button on)
-------------------------------------
| . | 131.156.3.3 | o | ("default" button off)
-------------------------------------
| . | 131.156.1.11 | o | ("default" button off)
-------------------------------------
Close the MacTCP panel.
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.
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.
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!
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!
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.eduin 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.
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 -------- 2On 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.2Avoid 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.
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.
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).
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.
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".
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.
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.
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
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.
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.
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.
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
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.
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
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.
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.
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.
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).
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.