1998 – The entire idea of a LocalTalk gateway is to bridge LocalTalk devices that don’t have ethernet – such as Macs, early LaserWriters, other printers, etc. which are not TCP/IP devices (visible on the Internet in the 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 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, some dial-up router, or something – one machine that handles the task of connecting to the Internet and sharing a connection. Well, we want to network, via ethernet, two other machines, as well as connect a Performa 475/Quadra 605 that doesn’t have an ethernet card. Instead, we want the P475 to use it’s built in LocalTalk support.
First, let’s describe the two ethernet machines – both are Quadra 610‘s with full FPUs 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 way TCP/IP works, when the other machine – the web server or whatever was contacted – sends the information back, it always includes this “encapsulated” header, which the router then receives, opens, realizes that this information is 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 that we need a router that will talk three languages. Ethernet, TCP/IP, and LocalTalk – all because of this P475 that we also want to connect to 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 an ethernet-to-LocalTalk bridge. It is only designed one way – i.e., printers can talk back to machines on 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, then 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 it works both ways. With LocalTalk Bridge, 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 System 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 (OT) is better if you can have in on all of them. For some machines, such as 68020 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 (VIG) or Apple’s Internet Router (AIR). It really depends on the system software you’re running on the machines. It seems that if Mac OS 8.0 is involved, AIR doesn’t seem to work right anymore, and you’ll need Vicom. If you’re running System 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.
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.
- Scott L. Barber
- Pres/CEO, SERKER Worldwide, Inc.
- Providing Hardware/Networking/Telecomm for 13 years
* Apple Internet Router is probably designed for MacTCP and not for Open Transport. Mac OS 7.6 and later only support Open Transport, while Mac System 6.0 through 7.0 only support MacTCP. For System 7.1 through 7.5.5, 68030, 68040, and pre-PCI PowerPC Macs support both, but Macs with PCI architecture only supported Open Transport, while 68000 and 68020 Macs only support MacTCP.
Scott L. Barber first posted this to Quadlist. It is reprinted with his permission.
Keywords: #localtalkgateway #opentransport #mactcp #appleinternetrouter
Short link: https://goo.gl/pcxWB2
searchword: localtalkgateway
