| MACINTOSH TCP | | Mark H. Solsman | Center for Academic Computing, Documentation Training and Publications | mhs108@psu.edu 10/26/93 I MacTCP and related Macintosh software ===================================== revision 1.1, November 15, 1992 ---------------------------------------------------------------- Copyright Eric Behr, Illinois State University, Mathematics Department This document can be freely redistributed in whole or in part, provided that this copyright notice is included intact, and that no material profit is generated from such a transaction. ---------------------------------------------------------------- With sincere thanks to: David N. Blank-Edelman dnb@meshugge.media.mit.edu Steve Dorner sdorner@qualcomm.com Patrick Hoepfner hoepfner@heasfs.gsfc.nasa.gov Peter N. Lewis peter@cujo.curtin.edu.au David S. Saunders dave@intercon.com as well as to several contributors to Usenet newsgroups, and to all those who sent me corrections and suggestions (but I'm the sole author of all mistakes, omissions and inanities) Please send all comments and suggestions to behr@math.ilstu.edu or to ejbehr@rs6000.cmp.ilstu.edu. The newest version of these notes can be obtained by anonymous ftp to spider.math.ilstu.edu, or 138.87.132.21 (file /pub/mac/mac-tcp.txt). CONTENTS PREFACE I. General stuff II. MacTCP III. Applications IV. Sources Appendix A. Peculiarities of Mac file transfers Appendix B. Elements of Macintosh networking Appendix C. Dial-in access PREFACE Judging by questions and pleas for help, more and more people are playing with MacTCP, and many of them are having problems installing and configuring it. I've spent many hours installing MacTCP on Macs ranging from the Plus to a IIci. I also devoted a large part of my free time to digging up various useful applications for use on the Internet. Hopefully some of my experiences will be helpful to you. Please note that I'm not a networking expert. Some of the advice below simply stems from my paranoia and is not necessarily based on facts. There are many problems with MacTCP which I don't fully understand. In addition, please remember that I'm not a technical writer, and my style may not be to your liking - sorry about that. Those readers who are new to the field of Macintosh networking might get something out of Appendix B -- please look at it before you continue. I. General stuff 1. Let's begin with a short sermon I started using the Internet several years ago, and it has become an important part of my life - for better or worse. I know that many people share my feelings about it. For the sake of all of us, please be considerate! There are lots of things you can mess up if you don't know what you are doing. Connecting your computer to the network which spans continents and is used by millions of people in their work is (or at least should be) a serious act. Please follow this simple advice: o when in doubt, don't do anything without consulting your local knowledgeable system administrator -- chances are that if you don't, you will break more than you'll fix; o find out how to access the Internet documents (esp. RFC's) and read the relevant ones before doing anything tricky; o read newsgroups such as comp.sys.mac.comm, comp.sys.mac.system, comp.sys.protocols.tcp-ip, comp.protocols.appletalk, especially the Frequently Asked Questions collections which are posted in most newsgroups from time to time; o read the flaming manuals! 2. Where does the Mac fit in? The Mac has always been a wonderful network machine. But for most people "Macintosh networking" means Apple's proprietary scheme called AppleTalk. The Internet uses a different networking "language". A major part of it is the protocol known by its acronym TCP/IP. To access the wonders of the Internet, a computer must understand TCP/IP. Even though there are other ways to make the Mac speak TCP/IP, we will concentrate on the most popular and orthodox one, namely the "MacTCP driver" from Apple. 3. Various connection methods The necessary software is only one part of a network connection. The other, obviously, is suitable hardware. A Macintosh can be connected to the outside world in many ways: o with a LocalTalk or PhoneNet connector (all Macs) o with a modem and suitable software (see Appendix C) o with an internal Ethernet card (Mac SE and newer) o with an external SCSI Ethernet adapter (all Macs) o with an internal TokenRing card (Mac SE and newer) Until recently MacTCP was not compatible with the last method of connection listed above. In mid-1992 Apple announced a Token Ring extension for use with MacTCP 1.1, which does the trick. Even though we have limited experience with that network driver, most of the advice below should apply to it. The problem of providing reliable and convenient dial-in access would require a separate book. A short note on this subject is found in Appendix C. Macs on Ethernet can usually connect to the outside TCP/IP world without a problem, since that protocol was to some extent created with Ethernet in mind. Macs on LocalTalk can communicate with the outside TCP/IP world only if the LocalTalk is connected to a larger network using an IP gateway such as FastPath (Shiva), Gatorbox (Cayman Systems), Multiport Gateway (Webster Computer Corp.), EtherRoute/TCP (Compatible Systems), or one of other equivalent devices; or if such a gateway is present elsewhere on your internet, and is visible to your Mac. None of the software routers like the Apple Internet Router or Liaison (Inphosphere) currently provides TCP/IP services, so if that's what you use to connect to an Ethernet, you must also have a gateway which will translate the IP packets wrapped in AppleTalk (which your LocalTalk Mac sends) into genuine IP packets going to the outside world, and vice versa. We briefly describe some of the details in Appendix B. Please note that AppleTalk and TCP/IP are two completely different animals, even though a single Mac can use both at the same time; configuring AppleTalk functions, such as printing over the network or AppleShare, will not be discussed here. II. MacTCP 1. How to get it? MacTCP (version 1.1 as of this writing) is marketed by APDA (408 974 4667). Don't expect your local Apple dealer to know much about it. Current price of a single copy is about $100. A site license is available, and some institutions may qualify for discounts. Call APDA. If you already have an old version, you should have no problems upgrading to the current one. Some public domain TCP/IP applications come bundled with MacTCP. This is somewhat paradoxical, but completely legal. The developer has paid Apple a rather stiff fee for a "distribution license". Technically speaking, you are allowed to use this copy only with the application it came with. Even though such a restriction seems a tad ridiculous, it is simply illegal to use a copy of MacTCP obtained in this fashion with *any* other application. Another catch is that you do not get manuals or upgrades this way, and configuring that beast - as you will see below - may be tricky. 2. What is it? For the user, it is a Control Panel, configured just as the Monitors or Sound CP. For applications, it is a set of procedures which allows them to communicate with other hosts on the network using the TCP/IP protocol. It is designed to be transparent in the sense that once it is properly configured, any correctly written application can make use of it without user intervention. Granted, life without MacTCP would be hell! In practice however, both MacTCP and the applications which use it have idiosyncrasies and bugs which make this software difficult to handle. In my own experience, the Mac SE is the most unstable MacTCP platform, probably because of the peculiarities of its ROMs; but I admit that it is a statistical observation, with no theory at all to back it up. Apple, in all its charming inconsistency, tells us to use their Installer even when adding a silly little printer driver, but at the same time does not provide an Installer script for the rather intricate procedure of installing and configuring MacTCP. Here's the way I've successfully done it on many machines. These are purely empirical findings, so treat these procedures more like a rain dance than a rational troubleshooting guide. 3. Let's do it! If you are installing MacTCP for the first time, or if you suddenly run into problems such as the dreaded message "Error opening TCP drivers - possibly no dynamic addressing", you should follow these steps for maximum effect. My general advice is: start with virginal (or at least freshly updated) system files. Problems may result from improperly installed old version of AppleTalk or other resources. For example, I could never painlessly install new Ethernet drivers on any Mac which previously had drivers for the Nuvolink SC box installed on it (I don't mean to put down Nuvotech's products - they usually work fine). What's worse, some network applications seem to corrupt the System, and/or other important files, when they crash. So here we go: o This is almost certainly an overkill, but in some cases it is also a recipe for instant happiness. If you are having major problems, boot from a system floppy, and trash the following from the hard disk: System, Finder, Multifinder, MacTCP, AdminTCP, MacTCP Prep, MacTCP DNR, all network drivers and control panels (AppleTalk, EtherTalk, Network). These gadgets are found in the System Folder proper (in pre-7 Systems) or in various subfolders, such as Control Panels, Preferences and Extensions. Of course, you'd better first back up all the files which seem important to you, such as non-standard extensions or fonts, which will get erased in the process! Then install a fresh system. o Disable all INITs, and non-essential network-related CDEVs, especially those which may be requesting network services at boot time (such as Network Time). Again, this probably isn't necessary, but who knows... As is well-known, many INITs produce mind- boggling conflicts. When you succeed in making MacTCP work without them, you should later reinstall them one by one, checking - say - telnet after activating each of them. If MacTCP conks out, you'll know the culprit! If that happens, please publicize your findings, or at least send a note to me. o If you will be using MacTCP over Ethernet, install network drivers according to manufacturer's instructions. For some reason I had better luck when I turned off AppleTalk in the Chooser before doing this. If you are installing Apple's drivers, make sure to use the latest Network Installer disk. If you will be using MacTCP through the serial (printer) port, activate AppleTalk in the Chooser now. Some Ethernet drivers, and the MacTCP Token Ring extension, also require AppleTalk to be active for MacTCP to work. o Configure the network drivers, if necessary. Most Ethernet drivers have no user-changeable settings at all. The Token Ring driver (configured via its Control Panel) should be set for the correct speed (4 or 16 Mbps). It also lets you set the hardware address of the adapter; if your site uses locally administered addresses, you need to get one from a local administrator, and set the driver accordingly. If you need your Mac's Ethernet hardware address for debugging purposes or simply for your records, you can get at it by holding option down while clicking the "Ethernet built-in" icon in the MacTCP panel. Another method is to log on to a nearby Unix machine, do a "ping" to your Mac's IP address, and then tell the Unix host to list its "ARP cache": arp -a on most systems. The hardware address will appear next to your Mac's name as 12 hex digits divided into pairs. Remember that Ethernet and Token Ring handle hardware addresses differently; if the Unix host and the Mac are on those two different types on networks, you need to translate each pair of hex digits into 8 binary digits, reverse their order, and translate the whole shebang into 12 hex digits to get the real hardware address. o Put fresh MacTCP, AdminTCP in the System folder. Make sure that you are using the newest version, and not some old beta copy obtained from shady sources. Under System 7+, they will go into the proper subfolder automatically. If you do have to use the older version 1.0 of MacTCP with System 7, you need to put these files in the top level directory (i.e. don't let the Mac put them in the Control Panels Folder; this is best done by dragging them into an open System Folder window, rather than onto the System Folder icon). Then make aliases to both of them and drop the aliases in the Control Panels folder. Otherwise MacTCP 1.0 will get confused. o In the next few steps in our procedure, MacTCP will create two files: MacTCP DNR and MacTCP Prep (under System 7 the latter should end up in the Preferences folder). You did remove the old ones, didn't you? Since some virus protection utilities might think that the new files that MacTCP is installing in the System folder are viruses, it is a good idea to shut off all virus protection before you go any further. o Configure MacTCP or AdminTCP (you will find more about that in later sections). Make sure you set the right network class and subnet mask if you use static addressing. You don't have to worry about that if you use a server such as FastPath or EtherRoute/TCP to assign addresses. For the time being, don't do anything with the "gateway" (should be 0.0.0.0) and "nameservers" (blank) fields. o Remember to set the correct physical layer setting ("Ethernet Built-in", "LocalTalk", or "Token Ring") in the MacTCP panel (if it gives you that choice). Let me reiterate that the physical link setting has nothing to do with the network resource (selected in the "Network" CDEV) which you will be using for AppleTalk functions, such as printing or AppleShare: we're dealing with strictly TCP/IP stuff. If your Mac is using a direct Ethernet connection for TCP/IP, you normally *don't need to* (nor should you, in some specific cases) activate AppleTalk or choose anything in the Network CP at this point. As we mentioned before, there are exceptions to this: some Ethernet drivers, and the MacTCP Token Ring extension, do require AppleTalk to be turned on in the Chooser. If you are using TCP/IP through the LocalTalk port, you must have activated AppleTalk in the Chooser before - otherwise that port is simply dead, and MacTCP doesn't know how to communicate with the outside world! On a Mac Plus, trying to reconfigure MacTCP with AppleTalk shut off will likely result in a horrifying "address error" or "illegal instruction" message. Don't worry - reboot, turn on AppleTalk and see if the new MacTCP settings are still there. If not, configure it one more time. Everything should be fine after that. o Even though MacTCP 1.1 doesn't always tell you to do so, REBOOT now! Check that MacTCP DNR (and usually MacTCP Prep) files show up in the System folder. o Older Macs, notably the Plus, become overworked while running System 7 (more precisely, the newest versions of AppleTalk) and MacTCP 1.1. Apple has released an unsupported patch which fixes the problem. You can get it from ftp.apple.com (see section IV, Sources, below). Do NOT install this patch unless: you have a Plus, *and* you run AppleTalk vsn. 56 or higher, *and* you use MacTCP 1.1. Another workaround is to use a SCSI Ethernet adapter instead of a LocalTalk connection; the SCSI port can handle this load, while the serial port controller can't. o Test MacTCP by running an application such as NCSA Telnet (the MacTCP version, of course). If the NCSA logo quietly disappears, you're in business. Try connecting to a *nearby* host by giving Telnet its decimalized IP address, such as 138.87.132.21. As of this writing, newest versions of NCSA/BYU Telnet sometimes produce a system error when they're run on a Mac Plus under pre-7 System. This might indicate a serious problem, but in 9 cases out of 10 this happens only the first time you attempt to run Telnet. Reboot and try again. o Assuming all went fine, you can now set the AppleTalk link in the Network panel if you wish (if AppleTalk was off, that is; this should also automatically turn on AppleTalk in the Chooser, but check it just in case). There are some exceptions here. For example if your Mac is on Ethernet, which in turn is connected to a Token Ring with the IBM 8209 bridge, activating AppleTalk might screw up TCP/IP. Details available on request. o If you can't connect to remote hosts, check if the "default gateway" field in MacTCP changes from the original 0.0.0.0 to something else after you start telnet or other MacTCP software. If it doesn't, then your Mac is having trouble discovering a gateway which connects your LAN with the rest of the world. You need to tell MacTCP where it is: enter its numeric IP address in the "default gateway" box. You may also want to tell it where the local nameserver for the root domain is (put a period in the "Domain" field, enter the IP address in the box next to it, click Default). To be on the safe side, trash MacTCP DNR and MacTCP Prep again; be sure to reboot the computer. o You should now be able to telnet to a remote host, and Telnet should be able to resolve symbolic addresses for you: e.g. nic.ddn.mil or sumex-aim.stanford.edu. If after all this you are still having problems, first check the hardware (is Ethernet up? are plugs plugged in? switches switched on? gateways are gatewaying? etc) Next, consider the possibility that some other node is using your IP address. See if things work if you change the IP address to another one from the range assigned to you. When MacTCP loads, it in effect asks the network: "host with IP number so-and-so, please respond". Your Mac's IP address is used in that query. If there is no answer, all is good. But if something out there responds, MacTCP correctly assumes that there is a conflict in IP numbers, and returns an error code which most applications then translate to a less-than-helpful message like "MacTCP is not installed correctly", or "Error opening TCP drivers - possibly no dynamic addressing". If all of the above doesn't help, buy a pair of tickets to Jamaica and invite your high-school flame along. After all, will you let a piece of steenkin' iron drive you nuts?! 4. Details... In the description below, we use the MacTCP control panel. The only difference between it and AdminTCP is that the latter allows you to lock and unlock the former; other than that, they are functionally identical. If the MacTCP panel you have has been locked, you won't be able to make any changes to it; you have to unlock it with AdminTCP first, or simply make all changes from within AdminTCP. After opening the MacTCP control panel, you should first set the physical link for the TCP/IP connection; for instance, if you use MacTCP on a LocalTalk network - whether gatewayed to an Ethernet, or isolated - select the "LocalTalk" icon. If you are directly on Ethernet, click the "Ethernet Built-in" icon. Now click the More button. In the first stage, you will be setting only three things: address assignment mode, network class, and network subnet. - If you are a "trusted and permanent" user who received a specially assigned IP address, click the "Manually" radio button. As a rule, it is best to have a permanent, static IP address. Some networks, however, have more nodes than addresses available to them. Such institutions resort to assigning addresses dynamically to those hosts (usually PCs) which request them; see the next subsection. Please remember that choosing an address at random will at best make your connections unreliable; it can also provoke unrestrained wrath of some powerful people in your organization. Courts have been known to drop bodily harm charges under much weaker extenuating circumstances. Moreover, some network numbers are illegal on the Internet. If you pick one of those, you'll be asking for a lot of trouble - in particular, you'll be getting all e-mail addressed to the University of Mars for the rest of your life. o The IP number you were assigned determines the network class. MacTCP is smart enough to figure it out by itself. You can also set it manually: addresses beginning with 1-127 are class A, 128- 191 indicates class B, and 191-254 are class C. Make sure you know what you are doing. o The netmask can be determined by stopping a friendly administrator in the hall and asking one or two simple questions. "Do we use subnetting?" And, "If so, how many bits form the subnet number?" If the first answer is "no", then slide the subnet mask indicator as far to the left as it will go. Such masks are 255.0.0.0 for class A networks, 255.255.0.0 for class B, and - guess what - 255.255.255.0 for class C. If your site does use subnets, the plot thickens. A number of address bits is set aside as the subnet number. You have to enter the subnet mask (such as 255.255.255.0, eight bits determining the subnet in a class B network) in the appropriate field; or you can delicately slide the subnet indicator to the right until it marks the right place. For example, if 6 bits are reserved for the subnet, you slide the thing from the leftmost position to the right by six little notches. Be forewarned: it is vital that all hosts which have the same network part in their address use identical subnet mask. You can avoid a lot of desperation in the future if you make sure you get this straight. 'Tis the time to read the manuals, perhaps? o Get out of the "inside" panel by clicking OK. Type your IP address in the edit field in MacTCP. Go back to the subpanel to verify everything is as it's supposed to be. If anything has changed all by itself, you are probably trying to set a wrong network class. - If you were told that "dynamic address assignment" is available to you, then all you need to do is click the Server radio button in MacTCP. Things should work automagically thanks to built-in intelligence of devices such as the FastPath, GatorBox, or EtherRoute/TCP. If there are problems, you have to get together with the person who maintains your gateway. - Many people prefer to avoid the "dynamic" button in MacTCP. Others have been using it successfully. There are situations when Apple's "dynamic addressing" is called for, but don't use it unless you have to. After you have entered all the required information, and you suspect that the user has itchy hands, it's time to click the "protected" box, close the panel and reboot right away. Remember to trash AdminTCP from his disk after you are done setting things up. If the user is likely to heed your advice, but might accidentally change the settings, click the "protected" box in AdminTCP, tell him not to fiddle with AdminTCP, and leave the control panel on his disk. This will save you some time and trouble when you have to change his settings again. If the prospective user is a TCP/IP sage, then you of course leave things wide open for him to play with the little buttons during long winter nights. There are some other permutations involving, for example, locking just the network part of the address, but leaving the subnet and node numbers accessible. Please read the manual! 5. More details After you have coerced MacTCP to work with this basic configuration, you may want to enter a few more things. The "Gateway Address" field in the MacTCP control panel should contain the IP number of the default gateway, i.e. the place where MacTCP should send packets if it doesn't know what else to do with them (i.e. packets addressed to a remote network). On most networks you will leave that field set to 0.0.0.0, and MacTCP will locate the default gateway by means of a magic wand called Routing Information Protocol (RIP). If your network for some reason does not implement RIP, you must enter a "real" address there. For example, if your Mac is on LocalTalk, you would use the address of a FastPath or another device which connects your network with the Ethernet. If you are directly on Ethernet, you should use the address of the router which connects that Ethernet to the campus network, or - if you don't have routers - the gateway which links your outfit with the rest of the world. You will also want to tell MacTCP where to find nameservers. Going into the details of the Internet Domain Name System (DNS) would make this document twice as long, so we will stick with the basics. The Domain Name System is used by computers to convert the human-friendly names such as "spider.math.ilstu.edu" to numeric addresses (IP numbers) such as 138.87.132.21. On occasion, computers use this system to "reverse-map" numeric addresses, i.e. to verify that your numeric address does correspond to a name which recognized by the DNS. If your network is connected to the Internet, your computer lives in some well-defined "domain". In my case, it is math.ilstu.edu, and a machine with address 138.87.132.21 is providing name service for that domain. I thus enter "math.ilstu.edu." (no quotes, but note the period at the end!) in the Domain field, and 138.87.132.21 in the Server field next to it. I also click the Default button. This informs MacTCP that my computer is in the math.ilstu.edu domain, so when I tell my Mac to telnet to "koala", it will query the nameserver about the address of the computer "koala.math.ilstu.edu". Here is the first row of edit fields on my Macs: -------------------------------------- | math.ilstu.edu. | 138.87.132.21 | x | ("default" button on) -------------------------------------- If the local nameserver doesn't keep a large table of addresses, or if it is less than reliable, you will probably want to put in some backup servers in fields below. In particular, one or more Domain fields could contain the period alone ("root domain", i.e. the entire Internet) with the address of a big, reliable machine next to it. Clicking the "default" button by no means guarantees that this particular server will be consulted first; MacTCP first contacts those nameservers listed in the control panel which seem to match the domain name included in the query - and only if that fails, the default server is asked as a last resort. However, all domain name queries should generally go to your local nameserver first. You may want to enter your local nameserver's address in the second row as well, specifying the root domain (period) in the first field. In my case, the second row would thus look like this: -------------------------------------- | . | 138.87.132.21 | o | ("default" button off) -------------------------------------- A small text file called Hosts can be put in the System Folder proper. I was told that some applications (e.g. VersaTerm) automatically create this file and modify it when needed. The Hosts file lets you enter additional information which MacTCP uses. For example, I could enter spider.math.ilstu.edu. IN A 138.87.132.21 math.ilstu.edu. IN NS spider.math.ilstu.edu. rs6000.cmp.ilstu.edu. IN A 138.87.1.2 rs6000. CNAME rs6000.cmp.ilstu.edu. ilstu.edu. IN NS rs6000.cmp.ilstu.edu. there to tell MacTCP that the computer spider.math.ilstu.edu has address 138.87.132.21, that it is a nameserver for my domain, that rs6000 in Computer Services has address 138.87.1.2, that I connect to it often enough so I want my Mac to use rs6000.cmp.ilstu.edu whenever I say "rs6000" (otherwise MacTCP would be looking for rs6000.math.ilstu.edu!), and that it is a nameserver for the domain directly above me. The use of periods at the end of domain names guarantees that MacTCP treats them as "absolute names", and doesn't try to append anything to them. If you know what you are doing, you can work with relative names (without the period) saving some space, typing, and quite possibly reducing the amount of memory MacTCP consumes - the current MacTCP implementation is rather limited in this respect. Assuming that my Macs are placed in the domain "math.ilstu.edu" by using the 'default nameserver' button in MacTCP, I could simply use "spider" instead of the absolute "spider.math.ilstu.edu.", because that extension would be automatically appended to a relative name without the period. For a list of specifications allowed in the Hosts file, see the MacTCP manual. After modifying the Hosts file or the nameserver information in the MacTCP control panel, make sure to trash the MacTCP DNR file, and reboot right away. 6. Odds and ends We end this section with a few miscellaneous problems reported in Usenet newsgroups or in personal communication. Sometimes the physical link icons (usually the "LocalTalk built- in" icon) mysteriously disappear from the MacTCP control panel. This seems to be caused by a bug in the recent Network Software Installer from Apple. If the MacTCP panel does not show any choices at all, it might help to zap the parameter RAM by holding down: command-option-p-r while restarting the mac (system 7) command-option-shift while opening the Control Panel (pre-7 systems) (reported by Mike Wiese of MIT in a Usenet posting). I haven't had much luck with this fix. Running System 7 and the TuneUp extension on a Mac broken in this fashion, I found that I had to reinstall the system and network files from scratch, then install, configure and test MacTCP, and finally install the TuneUp as the last step. Don't disregard the physical connection. I've seen several reports of strange problems which were eventually traced to a bad wire or transceiver. Some of Apple's "FriendlyNet" cables for use with the Quadras were involved. Borrow a working transceiver and cable from someone and try it before blaming everything on the software. Are things messed up, and you are stuck? Make sure to contact the vendor of the network adapter. There may be a problem which they know about. You may need to get an updated driver from them. It was reported that the Apple cache card (for the IIci) used to cause problems with MacTCP and a lot of other things. Scream for a replacement! Some cases of MacTCP applications freezing some machines (notably older SE's) seem to be caused by bad karma between MacTCP and the system ROMs. Matthew D. Heys a while ago reported extensively on his experiments. He empirically demonstrated that the freezes happen after a "cold start" (i.e. powerup), but do not occur after the computer is restarted with the programmer's switch or with the "Restart" in the Finder's "Special" menu. III. Applications There are many commercial programs which use TCP/IP connectivity (InterCon's family of networking applications, or VersaTerm from Synergy Software). I will not review them here because I have had little or no experience with them. Let the vendors speak for themselves. Some makers of similar commercial products are mentioned in Section IV for your convenience. The list of public domain or shareware software which follows will hopefully be amended and expanded in the near future - please send in your favorites! 1. Terminal emulation There are currently two popular freely available programs which let the Mac connect to other hosts as a terminal using TCP/IP (telnet): NCSA Telnet and its derivative, tn3270. The first one is being developed at the National Center for Supercomputing Applications in Urbana-Champaign. It emulates a vt100 terminal and provides some Tektronix graphic terminal capabilities; it also implements an ftp server function, i.e. when it's running, you can ftp *from* other hosts *to* your Mac. NCSA's version was modified somewhat by the Brigham Young University; NCSA/BYU Telnet implements a simple ftp client function. The second, tn3270 written at Brown University, is a variant of Telnet which provides the IBM 3270 terminal emulation. It also supports file transfers and printer sessions, but I don't know enough about our IBM big iron to actually try them out... NCSA Telnet comes in two versions: one which relies on MacTCP, and one which includes built-in TCP/IP drivers. If all you need is terminal emulation, the second version might be for you. Stanford University has developed a comprehensive package of TCP/IP applications collectively known as SU-Mac/IP. I didn't have a chance to try it. One advantage of Stanford's software is that it reportedly gives more informative error messages, which can be a great asset - especially when you are having problems! Contact macip@jessica.stanford.edu for conditions of a site license. If you know how to use MacBinary FTP, you can download the entire SU- Mac/IP documentation in MS Word format from jessica.stanford.edu (directory netinfo/macip/manuals4.0/users). 2. E-mail There are several schemes in which a Mac can access Internet mail. The crudest way, of course, is to telnet to a host on which you have an account, and use that host's mail facilities. Another is to keep using whatever mail system you have on the AppleTalk network (e.g. QuickMail or Microsoft Mail), and then provide a SMTP gateway which will translate it to Internet mail; this tends to be expensive and sometimes unreliable. By far the most popular and convenient system is the client/server method, in which one computer uses its powerful mail software and provides service to clients such as Macs or PCs. Macintosh users have the good fortune of being able to use some excellent mail clients which work on a Mac. Eudora written by Steve Dorner of UIUC leads the pack (in my humble opinion), with MIT's Techmail a close second. Eudora and other similar clients allow the user to read, compose, and edit mail on the Macintosh desktop; it can print mail, save messages as Mac files, and attach Macintosh-specific files (say, formatted Word documents or even applications) to the letters using the Macintosh standard BinHex encoding scheme (see Appendix A). When it's time to process mail, Eudora contacts the server, uploads messages waiting to be sent and downloads those which the server received for you. The (supposedly) well-maintained and well-connected server computer handles the rest, so you don't need to know anything about Unix or any other alien operating system. A special "Post Office Protocol" has been defined to handle this. There are two versions of it: POP2 and POP3. The server and the client have to agree on the version they speak. Most Mac clients, in particular Eudora, are POP3. If you succeed in sending mail, but attempts to check incoming messages fail, then it is very likely that your POP client and server use different versions of the protocol. It is easiest to set up a POP server on a Unix computer (popper from UC Berkeley seems to be the way to go here), but there are also servers operating under other systems, including one (POP2) which runs on a Macintosh. If you use a VAX with VMS, and some TCP/IP package is already installed, chances are that it includes a POP server. There is also a public domain POP3 server for VMS available from Indiana University, which a dear friend of mine, a computer semi-literate, got up and running without much grief. Talk to your local system administrator. For those of us who need to worry about PCs too, POPmail from University of Minnesota runs on MS-DOS machines and is compatible with both POP2 and POP3. A POP2 server running on a Mac is also available from that site. A Macintosh mail client is also included in Stanford's SU-Mac/IP package, available for a nominal fee. In case you don't have a reliable machine which may be used as a POP server, don't worry; your Mac can be made into a full-blown SMTP mailer, and it then behaves like any other "real" Internet mail node. Get Lee Fyock's LeeMail and try it out. I haven't, so I can only rely on second-hand reports which say that LeeMail might not be as smart as a full-blown Unix mailer, but it works just fine. Finally, a Swedish offering - MacPost - is something of a mixture of both methods; it has both a client and a server running on a Macintosh, but requires a Unix host as an intermediary for outside mail. The transactions between the individual clients and a MacPost server only use AppleTalk, and TCP/IP is only needed by the server Mac to communicate with the Unix host. I haven't used this one either, but who knows - it might be just the thing for you. Steve Dorner occasionally posts his much more complete list of Mac POP clients (including commercial ones) to newsgroups such as comp.protocols.appletalk and comp.sys.mac.comm. 3. FTP As we mentioned above, Telnet has limited ftp capability. But two other applications, XferIt and Fetch, are specifically designed to provide "FTP with a human face". Both present the directory on the remote host as a Macintosh dialog window, in which the user can select files to be downloaded. I've found minor quirks in both of them, but overall they are extremely impressive and useful. There is also HyperFTP, a HyperCard stack which is similar to the two applications. It is very solid, but relatively slow, and - naturally - it requires a reasonably recent version of HyperCard and consequently quite a bit of RAM. As with telnet and mail, an ftp application is also available as part of the SU-Mac/IP software. When using FTP from a Mac, you should realize that many anonymous FTP sites do not allow connections from hosts which are unknown to the Internet nameservers. To connect to such nodes, your Mac's IP address has to "reverse-map" to a legal Internet name, like mac1.math.ilstu.edu. The system administrator of your nameserver computer might be willing to enter your address in his database. See Appendix A for a very short introduction to the intricacies of Macintosh file transfers. For more information on the procedures involved in FTP'ing Macintosh files, read the text file ftp- primer.txt, which can be found on sumex-aim.stanford.edu in the directory info-mac/reports. 4. Network news As with FTP, there are three applications and one HyperCard stack designed to let you access news: TheNews, Newswatcher, NetNews (stack), and Nuntius. I have not experimented with Nuntius, so I can only quote second-hand information: at least one of my correspondents swears by Nuntius as "the best newsreader I have seen on the Mac by far". There are minor problems with each of the three, compounded by the fact that this method of reading Usenet articles usually involves downloading humongous lists of articles over a slow connection such as overloaded LocalTalk, keeping track of read items, and so on. This is not for the faint of heart. Many people still stick to the old-fashioned method of logging on to a bigger host and reading news there. But when it works, it's worth it! You can finally organize the saved articles on your own disk, use your favorite word processor to write replies, etc. I hesitate to recommend specific choices, but personally I have found the newest NewsWatcher to be very stable, powerful and easy to use. News clients require an address of a nearby friendly NNTP server. The server needs to be friendly in the sense that it must recognize your Mac as a host which is allowed to post news. This also requires having a valid domain name (see above under FTP), and the server must have been configured to accept uploads from your computer. Even though many servers allow free read access but limit posting, the Mac clients will usually give up without explanation unless they are granted both permissions. This causes a lot of confusion among novice users, who later post complaints about "broken newsreaders". 5. Miscellaneous gadgets There are dozens of useful or simply nifty applications which use MacTCP. Here are two of my favorites. Network Time written by Peter Resnick is a CDEV which periodically contacts an Internet timeserver, like merit.edu or nic.ddn.mil, looks at the Map CDEV to determine your location (and hence time zone offset; I particularly like this elegant touch), and sets your Mac's clock. After installing it you can boast that your screen clock is accurate to a tiny fraction of a second. Finger and fingerd by Peter Lewis give Macs the Unix "finger" capability. Finger sends a finger query to a remote host; it's even smart enough to automatically put people whom you "finger-ed" in a menu, so you don't have to type their address again. Finderd simulates a finger daemon on your Macintosh, so other people can finger you while you are simply working on your Mac. Peter has released another fine product - Talk, which simulates a Unix "talk" client and daemon on the Macintosh. A third gadget written by him, Chat, turns a Mac into a simple conferencing center (a la IRC, for those who have used it). Peter's latest product, ftpd, runs in the background under System 7 and makes the Mac into an ftp server. The Internet Gopher searches "gopher servers" on various Internet hosts and retrieves various information such as directory entries, class schedules, campus newsletters, etc. One Macintosh client is a HyperCard stack written at University of Minnesota. It has been recently superceded by an application called TurboGopher, which definitely lives up to its name. Another standalone version, GopherApp - still a bit quirky (e.g. it cannot retrieve documents larger than 50KB or so) but promising - comes from Indiana University. Wide Area Information Service is a fruit of a joint project of Apple Computer, Thinking Machines, Peat-Marwick and Dow Jones. There are several WAIS servers in operation; they can be queried from a Mac by means of an application called WAIStation. A WAIS server can also be accessed by telnet to quake.think.com (login name wais), but the interface is then much less friendly. Check it out! It's a glimpse at the things to come. There is no doubt that someone out there is sweating over a Mac version of the Archie client (for searching directories of anonymous ftp servers), but I'm not aware of a finished product. MIT's TechInfo is another impressive example of a fast and easy to use information retrieval system. MIT and a few other institutions run servers which store and search databases of campus events, faculty and student directories, etc. Both Mac and PC clients are available. If your Macs use the CAP AppleShare server, chances are you'll want to look at MacDump, which permits automated backups of your Mac volumes onto the CAP server. A desk accessory called Client DA (written by Greg Anderson of UC Santa Cruz) connects to the Unix daemon "supersrv" (by Steven Grimm), which in turn uses the wonders of Unix to do whatever you want it to do. For example, a trivial Unix shell script invoked by supersrv allows our faculty to search all users on the system, or access the archie ftp search facility directly from their Macs. Client DA has some problems with smaller Macs, and I wish someone kept maintaining this wonderful gadget. On the lighter side, we have GameMaster, which lets you play a variety of games over AppleTalk and TCP/IP networks. There is also a Macintosh version of ping, called Mping; it is available from ftp.apple.com as one of the examples of a TCP/IP application (file /dts/mac/netcomm/mactcp-1-1-examples.hqx). There is a bare-bones prototype of an SNMP management console on ftp.apple.com, in the file /pub/apple-ip/snmptool1.0d7.sit.hqx. I found it to be quite buggy (maybe I just don't know how to use it). But I did manage to obtain all data from my EtherRoute gateway using it. Please let me know what are your favorites in this category - I'll be happy to expand this section! IV. Sources 1. Downloading text files Use any account available to you on a well-connected host. Type "ftp sumex-aim.stanford.edu" (or if that doesn't work, try "ftp 36.44.0.6"). Type "anonymous" as login name, and your mail address as password. In 9 cases out of 10, archives such as this one accept "ftp" in place of "anonymous", which means that you can delay the onset of carpal tunnel syndrome. You will also discover that many sites will accept any password at all, but let's be nice to those folks who specifically ask for the real id. Enter "cd /info-mac/report", and then "get ftp-primer.txt". When you see "Transfer complete", type "quit" and read the file you just downloaded. After becoming skilled in using ftp, download some more text files from the /info-mac directory: help/accessing-files.txt report/how-do-i-find.txt report/internet-access-11.hqx report/ftp-sites.txt A Macintosh communications FAQ ("frequently asked questions") list is an invaluable source of information. It is posted periodically in the Usenet newsgroup comp.sys.mac.comm; it is also available for anonymous ftp on rascal.ics.utexas.edu as communications.FAQ in the directory mac/faq. The anonymous ftp site nnsc.nsf.net run by the National Science Foundation is a good source of background information about the Internet (see directories /nsfnet and /info). 2. What next? When you have learned how to download Macintosh executable files, it's time to go hunting for specific applications. WARNING!!! The minute you start downloading files from the network, you become more susceptible to viral infection than before. I strongly suggest that you should first get and set up the wonderful free virus checker, Disinfectant. Its home is ftp.nwu.edu, in directory /pub/disinfectant; it can also be found in many other places, e.g. on sumex-aim.stanford edu in the directory /info-mac/virus. You may then want to send its author, John Norstad, a nice thank-you note: we all owe him a great deal! If you have access to Usenet news, make it a habit to monitor the comp.sys.mac.announce group: it is probably the most reliable source of information about newly discovered viruses. Here is a list of applications which were mentioned above, and which can be found on sumex in the directory /info-mac. There are many servers which maintain copies of /info-mac contents, such as wuarchive.wustl.edu in /mirrors/info-mac. The names are aren't exact: many version numbers have certainly advanced quite a bit by the time you read this. comm/chat-10.hqx comm/fetch-21.hqx comm/finger-135.hqx comm/hyperftp-13.hqx comm/lee-mail-124.hqx comm/ncsa-telnet-25.hqx comm/news-watcher-102.hqx comm/nuntius-111d12.hqx comm/the-news-22.hqx comm/xferit-14.hqx cp/network-time-111.hqx game/game-master.hqx Software found on ftp servers other than sumex: ClientDA: ssyx.ucsc.edu (supersrv is there as well) Eudora: ftp.cso.uiuc.edu in /pub/mac/eudora (also on ftp.qualcomm.com) GopherApp: ftp.bio.indiana.edu in /util/gopher MacDump: bbn.com MacPost: pollux.lu.se in /pub/mac/comm MacTCP+ patch: ftp.apple.com in /ftp/dts/mac/netcomm MPing: as above, file name mactcp-1-1-examples.hqx NCSA/BYU Telnet: bert.cs.byu.edu NetNews: ftp.bio.indiana.edu in /util/mac POPmail: boombox.micro.umn.edu, in /pub/POPmail popper: lilac.berkeley.edu SU-Mac/IP: send e-mail to macip@jessica.stanford.edu TechInfo: net-dist.mit.edu in /pub/TechInfo TechMail: net-dist.mit.edu in /pub/TechMail tn3270: brownvm.brown.edu TurboGopher: boombox.micro.umn.edu in /pub/gopher WAIStation: think.com in /wais A list of anonymous FTP sites (not only Macintosh-related) is maintained on pilot.njin.net. Many Unix hosts (and an increasing number of other machines) will also let you search an archie database of anonymous ftp sites. This should keep you busy for now... 3. Contacts for commercial products Please remember that I do not in any way endorse commercial products by listing the vendors here, and I'm not in any way associated with them. This is simply for your convenience. Phone numbers are followed by an anonymous ftp server which can be used to get free upgrades and information, or an e-mail address. Cayman Systems (800) 473 4776 ftp.cayman.com Compatible Systems (800) 356 0283 csn.org, in /compatible Farallon Computing (800) 344 7489 farallon.com Intercon Systems (703) 709 9890 sales@intercon.com Shiva (800) 458 3550 shiva.com Synergy Software (215) 779 0522 D2296@AppleLink.Apple.COM Webster Computer Corp 011(?) 61 3 764 1100 (Australia) 4. Let's end with a short sermon... Many of the applications mentioned above are NOT in public domain. They are either shareware, or there are restrictions on their use and/or distribution. PLEASE PAY FOR SHAREWARE YOU KEEP!!! Author's address can almost always be found by pulling down the Apple menu and selecting "About..." Let's keep this wonderful, affordable software alive! Appendix A. Peculiarities of Mac file transfers Macintosh files differ from files on most other machines in that they consist of two parts. One contains data (text, executable program), and the other - resources (icons, the file's creator code, etc.) I'm simplifying .