The LocalTalk Gateway

Scott L. Barber first posted this to Quadlist. It is reprinted with his permission.

The entire idea of a LocalTalk gateway is to bridge LocalTalk devices - such as Mac Pluses, LaserWriters, other printers, etc., that are not TCP/IP devices (seeable on the internet, in internet's most common language) AS LocalTalk devices. With a Mac Plus, this is rather easy. With Printers,it becomes a little more software intensive. Either way, you need something to "bind" the LocalTalk protocol to this TCP/IP, so that this machine has an address on the internet that can be used.

Now that gets a little complex in the explaining, so I'll jump right into the example.

Say you have an internet connection - via either a dedicated router, or some dialup router, or something - one machine that handles the task of dialing into the internet, and getting a connection. Well, we want to network, via ethernet, two other machines, as well as connect a Performa 475 that doesn't have an ethernet card. Instead, we want the P475 to use it's built in LocalTalk support.

First, lets describe the two ethernet machines - both are Quadra 610's with full FPU's and 68 MB of memory. One is just a terminal - we use it all the time to browse the web through the router. It's address is simple - 10.0.0.1. Our router knows that 10.0.0.1 is on the local network, and routes to the internet for this machine, over ethernet, without issue. The other Quadra 610, known as 10.0.0.2, is also known by the router, and the router sends out and receives data from the internet for this machine as well.

One of the neat things about this router is that the internet only sees THIS machine - this router - as the only machine connected to the internet - when it connects, it dials up to the internet and becomes 222.222.222.222. This happens to be the number it gets, and it's damn happy about it. What the router does though, is whenever 10.0.0.1 or 10.0.0.2 send any information to the internet, the Router encapsulates this request in a special header, and sends it out to the internet as if >>it<< has sent the request. Because of this special header though, and the was TCP/IP works, when the other machine - -the web server or whatever that was contacted sends the information back, it always includes this "encapsulated" header, which the router then receives, opens, realizes that this information was destined for 10.0.0.1, and passes it on to our 10.0.0.1 machine. Neat, eh? That's all a router does . . . really simple.

Now . . . we get more complex. Our problem is, we need a router that will talk three languages. Ethernet, TCP/IP, and LocalTalk - because of this P475 that we ALSO want to reach the internet. Well, someone out there got really smart, and built a box that routes all three - Farallon has versions of the Netopia that can have LocalTalk networks just plug into the side - cool, and expensive. For us cheap people, read on.

We can do this in a couple of stages . . . it's really quite simple. Apple made a free program called LaserWriter Bridge, which allows a machine to "route" LocalTalk data into ethernet data, just like our "router" routes Ethernet to TCP/IP. For those of you jumping ahead, it seems that if we could just turn LocalTalk into ethernet, then the ethernet would jump to TCP/IP through out big router, and you're right unfortunately Apple didn't give that kind of two way thinking to LaserWriter Bridge I'll explain.

LaserWriter Bridge is kind of a one way street - it allows Ethernet networks to use a dedicated machine as a ethernet to LocalTalk bridge. It is only designed one way -- i.e., printers can talk back to machines on the ethernet that started a conversation with them, but the printers themselves cannot contact the machines on their own - if a Mac Plus, or Performa 475 were on the LocalTalk part of this network, they'd not be able to see any other devices but the other LocalTalk devices on the network. An example is in order.

With our three machines, turn file sharing on for each of these machines. 10.0.0.1 is named Q1, then Q2, then P1 . . . follow? So, when Q1 opens it's Chooser window, it sees Q2 and P1 as login choices. When Q2 opens it's Chooser, it sees Q1 and P1, no problem. But when P1 opens it's Chooser window it sees nothing - to P1, there are no other machines on the network to talk to - it's all alone.

But wait, If Q1 sees P1 in it's Chooser window, the P1 isn't alone! That's right - Q1 can log into P1 and mount it's drives - but not vice versa - Q1 HAS to start the conversation, and announce it's presence by "tapping" P1 and letting it know it's there . . .

So, after all this . . . Is there a solution?

Well, yes, and no . . . it costs a little money now . . .

Apple also made another program called Apple >>LocalTalk<< Bridge, which does the same thing as LaserWriter Bridge, but works both ways . . . with LocalTalk bridge, you P1 sees both Q1 and Q2 without problem. It's a FULL bridge . . .

For LocalTalk bridge to work though through the internet, you'll still need a few tools. Make sure that every machine is running the same version of AppleShare (the current version is 3.7.4). This eliminates a lot of problems, and 3.7.4 even runs on 7.5 machines, and even lower, I think . . . just as long as they're the same language follow? Next, you'll need to have either Open Transport or MacTCP running on all the machines - Open Transport is better - if you can have in on all of them. For some machines, such as 020 or lower, MacTCP is the only choice, and more software is required for MacTCP in this situation than in others . . .

The Open Transport process.

The easiest solution for OT is to use the MacIP protocol (this is AppleTalk). This often requires setting up the MacIP gateway manually, using 10.0.0.2 as the gateway, and setting up OT on the 10.0.0.2 machine to use AppleTalk for routing as well. This is a bit complex, and I don't have the mind to get into it now, but it's also posted across the internet, and can be put together in about an hour. Sorry I don't have my faculties together for this, but I'm more interested in the MacTCP process than the OT process, simply because this is built into OT 1.1.2 and higher.

The MacTCP process.

For MacTCP, you'll need one of two programs. Either Vicom Internet Gateway, or Apple's Internet Router. It really depends on the system software you're running on the machines. It seems that if System 8.0 is involved, AIR doesn't seem to work right anymore, and you'll need Vicom. If you're running 7.5.5 or less, AIR works fine. Either way, they accomplish the same thing . . .

Remember when I mentioned earlier that our internet router was 222.222.222.222, and that we were "encapsulating" data from 10.0.0.1 and 10.0.0.2 as if it were coming from 222.222.222.222? Well, here we go again with a little bit more information. To the internet, the router is 222.222.222.222, but to the local network, we have to give this router the ability to have TWO IP addresses - an address that 10.0.0.1 and 10.0.0.2 can see . . . in this case, our router is set up to appear as 222.222.222.222 to the internet, and 10.0.0.50 to our network - this way, it acts as a "gateway" between our network and the internet. So a gateway has to have two addresses - one for the inside, and one for the outside - the gateway must be on BOTH networks . . . .(yes, we consider the internet one big single network in this case).

So, when running AIR or VIG, we have to do the same thing . . . so we cheat again, Our Quadra 610 - Mr. 10.0.0.2 -- gets another address from AIR or VIG - one we pick, and one that's only visible to our LocalTalk buddy - the P475. We choose 10.1.1.50, and set the P475 to 10.1.1.1. Neat, eh? Things are routed twice from the P475 before they hit that single network called the internet - cool . . . well . . . not so cool.

When you hear about routing, this happens, over and over and over - and that encapsulated header can be encapsulated over and over and over, with new leads, with new server information, with new header codes, so that layer after layer are applied, and the packet, when received by the web server on the other side, can be sent back to the original requester (the P475) like the trail of bread crumbs that Hansel and Gretel left along the way. It works in TCP/IP, and that's the closest to a technical explanation of how TCP/IP actually routes as I plan to come in this document.

End of document

To be honest, I'd say look at a 75, and get the POTS support . . . we were able to eliminate the house phone lines, and take advantage of incredible long distance areas and deals on ISDN compared to regular phone lines. I'm paying nothing inside my area code, and 6 cents a minute outside all the time. International is locked at 75C per minute. Not >too shabby, and you can eliminate the business phone lines that cost $25@.

This has got me intrigued. I've never realized you could balance off ISDN costs this way and would like to get more details either through the list or e-mail. My ISP offers ISDN at no extra charge so that helps too.

But getting ISDN to your house might be a bitch in price. It runs around $100 a month for the ISDN phone line here, but you do get the ability to split off both 64k channels as voice whenever needed. I have a client that dials into me via ISDN, and he also uses these lines as his primary voice and fax lines - when the phone call via voice ends, the Ascend just redials my server, and picks back up at 128k instead of just 64k. The only time he's off my network is when both lines are called with voice . . . it's neat . . .

you'll need an ISOBAR to make sure that your lines are kosher - ISOBAR's actually check polarity, since most idiot electricians like to connect the white and ground wires inside the box (this is wrong, but passes most code). In this case, mismatching your black and white on an outlet will overheat a lot of computer equipment . . .

Wow, someone else has heard of Trip-lite! I usually get blank stares from folks on this amazingly enough. I went one step farther and actually use a

I do as well. I'm the only consultant in my area that actually sells the things now, just so I could have them in the area. I live by this brand, and have never had a problem with them that Tripp-Lite didn't solve without a hitch. There is no other surge protector for me or my clients. (Yes, I'm VAR for them . . . but I felt this way before I became VAR.) 

Scott L. Barber <serker@earthling.net>

Pres/CEO, SERKER Worldwide, Inc.

Providing Hardware/Networking/Telecomm for 13 years

Quadlist, the listserv for users of 68040-based Macs. FAQ at <http://lowendmac.com/lists/quadlist.shtml>