jeff@tc.fluke.COM (Jeff Stearns) (04/05/89)
I have CAP installed and running. I'm holding a floppy disk containing
Dartmouth's Async AppleTalk. We have Macs and modems. We also have a
GatorBox.
It seems like these are the ingredients for doing Something Interesting.
I'm thinking of creating a simple scheme so that a Mac running Async AppleTalk
can dial up from home and access files on the NFS.
There are several options. Absolutely easiest would be to use a GatorBox
as a NFS<->KIP bridge; all that's missing is a KIP<->Async AppleTalk "repeater"
process running on, say, a Sun.
Or use the GatorBox as an NFS<->EtherTalk bridge, and write an
EtherTalk<->Async AppleTalk "repeater" program for the Sun.
A third option would be to skip the GatorBox and do all the work on the Sun.
This seems like substantially more work, because the Sun now has to play the
role of an AppleTalk bridge. Still, CAP gives a good head start on the
problem; it seeems like I could rewrite the AUFS packet driver so that it
speaks Async AppleTalk instead of KIP.
It seems so straightforward that I'm sure others have already done it.
What problems did you run into? Was it worth the trouble?
--
Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064
jeff@tc.fluke.COM {uw-beaver,microsoft,sun}!fluke!jeff
PS - Calling all users of the Vitalink TransLAN IV Ethernet bridge! Please
drop me a line.verber@pacific.mps.ohio-state.edu (Mark A. Verber) (04/05/89)
Charlie Kim wrote an AppleTalk bridge that would run on a Sun under SunOS 4.0 and some modern?! version of Ultrix. It is called uab and is ftpable from cunixc.cc.columbia.edu. --------------------------------------------------------------------- Mark A. Verber Physics Department verber@mps.ohio-state.edu Ohio State University 174 West 18th Avenue 614-292-8002 Columbus, OH 43210 There are two major products that come out of Berkeley: LSD and BSD UNIX. We don't believe this to be a coincidence.
djh@munnari.oz (David Hornsby) (04/06/89)
In article <7560@fluke.COM> jeff@tc.fluke.COM (Jeff Stearns) writes: >I have CAP installed and running. I'm holding a floppy disk containing >Dartmouth's Async AppleTalk. We have Macs and modems. We also have a GatorBox. >It seems like these are the ingredients for doing Something Interesting. I have just been through the process of implementing Asynchronous AppleTalk for connection to UNIX boxes. The method I chose was to take the Async code written by Richard E. Brown et. al. at Dartmouth (as presented in Dr. Dobbs Journal of Software Tools) and make an adev for use with the 'Network' cdev and the LAP manager. The adev gives you a login window to allow you to make a connection to a UNIX host, and run a UNIX process which then connects you to AppleTalk. To avoid having to write an AppleTalk bridge under UNIX, we modified the gateway code in our locally designed gateway** . The status of the project is that it has been distributed within in Australia for testing and use. In order for it to be usable outside Australia, someone will need to apply a trivial modification to the kbox/gatorbox code. Any volunteers ? I would also like to see some discussion on some of the decisions made in the implementation, so I am including the README file from the distribution. If you have any comments, please mail me or use this newsgroup as a forum. DON'T ASK FOR THE DISTRIBUTION YET, IT WON'T DO YOU ANY GOOD - IT WILL NOT WORK UNTIL SOMEONE HAS THE TIME TO CHANGE SOME GATEWAY CODE. The next step is to investigate Charlie Kim's UAB code so that the whole lot can be merged, I haven't had time to do this yet ... - David. ** The gateway is called Multigate. It is a four channel AppleTalk to EtherNet gateway designed by the University of Melbourne Department of Computer Science and now being built in Australia by Webster Computer Corporation. README:------------------------------------------------------------------ Asynchronous AppleTalk for UNIX/CAP hosts - Request For Comment. 17/10/88 ------------------------------------------------------------------------- The Department of Computer Science at The University of Melbourne has developed and is currently testing a version of Asynchronous AppleTalk for remote AppleTalk access via UNIX/CAP hosts. This system is based on the code presented in the October 1987 issue of "Dr. Dobb's Journal of Software Tools" by Richard E. Brown and Steve Ligett of Kiewit Computer Centre, Dartmouth College, Hanover, New Hampshire, and contains later protocol extensions. The UNIX code uses some library routines and database files from the Columbia AppleTalk Package (CAP) developed by Charlie Kim, Center for Computing Activities at Columbia University. The purposes of this document are to discuss the problems encountered and the solutions used in implementing Asynchronous AppleTalk capability on a UNIX host and to solicit comments from interested parties. Background: Asynchronous AppleTalk replaces the normal Link Access Protocol (LAP) used on LocalTalk networks with an Async AppleTalk LAP (AALAP) which sends AppleTalk frames over an async link such as a modem or twisted pair. To achieve this, one usually needs to purchase extra hardware to connect to the other end of the link and to bridge to a normal LocalTalk network. After some discussions and experimentation, it was decided that it was possible to use a UNIX host which already had ample dial-up facilities to perform this function. This naturally left some problems to solve ... 1. How to use the Macintosh to perform the functions of dialling a modem and allowing a normal login. Most async implementations could dial modems but fell short of giving a login window. SOLUTION: massage the Async code from Dartmouth to provide a window and speed/parity dialog box. At the same time, it was felt that the system should conform to current Apple standards for choosing alternate LAPs, therefore implement as 'atlk'/'adev' resources. NB: the window currently emulates a VT52. STATUS: complete, testing. 2. How to get AALAP packets onto LocalTalk networks. SOLUTION: repackage packets from the serial line as UDP encapsulated DDP packets (otherwise known as KIP format) and send them via ethernet to the local gateway (a Multigate in this case but Kboxes should do). PROBLEM: How do we know who the local gateway is and who we are ? The current solution is to use the file 'atalk.local' with a new (4th) line. The file now looks like this ... --------------------atalk.local------------------------------- # myNet myNode myZone 93.30 26 unimelb-CompSci # host information # bridgeNet bridgeNode bridgeIP 93.20 23 128.250.1.23 # bridge information # nisNet nisNode 93.30 26 # Name Info Server info. # asyncNet asyncZone 170.26 unimelb-Async # Async Info (***NEW***) -------------------------------------------------------------- See below for explanations of Async information. 3. How to get packets back to the UNIX host to send via AALAP. This is a bit trickier because we need to allow Async Macs to have different node numbers and KIP/CAP has no mechanism for more than one node number per host (yet). SOLUTION: Map Mac node numbers into a UDP user port range and have the gateway forward anything destined for node N on an Async network to the host UDP port = N + PortOffset [PortOffset has notionally been assigned the value 43520 (0xaa00)]. This port is monitored by our user process. Additionally, we have to assign a new AppleTalk network number to our UNIX host and make a suitable entry in the file atalkatab to tell the gateway of this arrangement. IE: ------------------portion of atalkatab------------------------ # Test Asynchronous AppleTalk network 170.26 A 128.250.1.26 unimelb-Async # async net running on munnari -------------------------------------------------------------- Where: "170.26" is the Async AppleTalk net number on this host 'A' indicates this is an Async net "128.250.1.26" is the host IP address. "unimelb-Async" is the zone assigned for testing the code. PROBLEM 1: gateways won't normally do this, we have to modify the gateway KIP code. The modification is minor but requires the acceptance and cooperation of the network community. The 'A' flag is equivalent to the 'H2' flag not currently in use. We have modified 'atalkad.c' to recognise 'A', the modification is trivial. PROBLEM 2: Broadcast packets! We obviously can't have a gateway sending to all the 254 possible UDP ports (node numbers). The current solution to this problem is to assign a Well Known Socket for broadcast packets (currently 750). An Async daemon running on the host monitors this port for: 1. notification from user processes that they have started and are using node number N. 2. broadcast packets sent from the gateway for redirection to the port N + PortOffset. STATUS of 2 & 3: Complete and testing. DISTRIBUTION POLICY: In the current spirit of the CAP/Async communities, the UNIX sources and the Mac 'adev' will be available to anyone provided that the system is not sold for profit or otherwise abused and that improvements return to the author for inclusion in the distribution. (NOT AVAILABLE YET) Please send comments, requests for information to ... djh@munnari.oz.au David Hornsby Professional Officer Department of Computer Science Richard Berry Building University of Melbourne Parkville 3052 Victoria, Australia