Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!ukc!icdoc!qmw-cs!liam From: liam@cs.qmw.ac.uk (William Roberts;) Newsgroups: comp.unix.aux Subject: Re: remote access from MacOS to A/UX over Appletalk? Keywords: Expensive, Unfriendly, Difficult, Apple Message-ID: <2793@redstar.cs.qmw.ac.uk> Date: 11 Dec 90 11:18:33 GMT References: <18256@hydra.gatech.EDU> <1990Dec8.045720.1507@wiskit.pdx.com> Sender: usenet@cs.qmw.ac.uk Lines: 31 Nntp-Posting-Host: whitesand In <1990Dec8.045720.1507@wiskit.pdx.com> herbw@wiskit.pdx.com (Herb Weiner) writes: >As far as I can determine (Apple, please correct me if I am wrong), there >is a brick wall between A/UX programs (like Daemons) and AppleTalk. They >can NOT access the Communication Toolbox. They can not access the AppleTalk >drivers. The ONLY thing they can do is print over AppleTalk. A/UX programs don't talk to the Comms Toolbox - correct. A/UX programs can and do access the AppleTalk protocols, which are actually implemented in A/UX as Streams drivers: the AppleTalk drivers for the A/UX Mac emulation are actually dummies which work through the A/UX kernel code, but it isn't clear where the split is (the kernel PAP code is probably not used by the Mac emulation, for example). My changes to CAP make use of the A/UX AppleTalk support: the relevant manual pages are in section 3N called lap, ddp, atp, nbp, pap, and zip. These manual pages don't offer much help and don't seem to include ADSP. As for your original problem, the short cut would be to hook into the AppleTalk streams stuff to get the IP-in-DPP packets fed back into something that looks to the kernel like an Ethernet interface, then use NCSA telnet. Given ADSP you'd use that instead with a specialised version of getty. Neither of these things currently exist. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)