Path: utzoo!utgpu!watserv1!watmath!att!linac!uwm.edu!zaphod.mps.ohio-state.edu!caen!umich!terminator!terminator.cc.umich.edu!cmclark From: cmclark@terminator.cc.umich.edu (Charles Clark) Newsgroups: comp.protocols.appletalk Subject: Re: Need help with MacTCP Summary: No, he really should be using SERVER Keywords: MacTCP Message-ID: <1991Jan14.064043.3618@terminator.cc.umich.edu> Date: 14 Jan 91 06:40:43 GMT References: Sender: usenet@terminator.cc.umich.edu (usenet news) Organization: U of Michigan, ITD Research Systems Lines: 88 In article hobson@elbereth.rutgers.edu (Kevin Hobson) writes: >In article , makmur@athos.rutgers.edu (Hanz Makmur) writes: >> I have lots of Mac behind Kbox with no HD and students is given a >> disk to access AFP servers. To be able to use any TCP stuff, >> I am to include mac TCP into each floppy. > >You are assuming that it is zonename dependent. It is not. It is IP >subnet and host number dependent. > Actually, MacTCP is somewhat zonename dependent. > > I would be very interested in this since you will have to use >the DYNAMIC function of MacTCP in order to get this to work. No, he will not. >> All the Macs are behind ddp/ip gateway (Kbox)and their IPs are assigned >> dynamically. The MacTCP is set to SERVER. >> > > SERVER should not work since it assumes hard-coded IP address >(same subnetted IP network). DYNAMIC would be the correct option but >you are in a particular bad situation. Dynamic should take the dynamic >address assigned by the gateway. No. You do not understand what SERVER and DYNAMIC mean to MacTCP. Server means that it checks over AppleTalk for an IP address server and gateway (FastPath, Gator, Webster, whatever). Dynamic means that you configure MacTCP with a range of IP addresses to choose from, and it does so and tries to see if it is in use, and then uses it. >Your major problem will be with the >gateway configuration in MacTCP since it assumes that the users are >behind the same gateway everytime. No again. In SERVER configuration, the Gateway Address field is ignored (it is not even setable!). All you do is set it to be SERVER, set the class of the IP network (A, B, or C) and the subnet bits. And that is it, all you need to do, all MacTCP needs to know to get an address from the FastPath (or whatever). >> Any help you could provide will be appreciated. >> >> Thanks >> Hanz Makmur > >Send me mail to set up and appointment and I will explain in person if >you need further explaination. Not to be personally insulting, but it sort of sounds like you didn't understand the question correctly and/or haven't read the MacTCP manual (or messed with MacTCP enough) to understand how it gets an address. I personally don't know why MacTCP has to be reconfigured for the proper zone when using LocalTalk. My guess is that a ddp/ip gateway could possibly serve addresses to Macs in different zones (but having their gateways on the same ethernet). Therefore you want to ask an IPaddress server in the non-default zone for your number. It would be nice of MacTCP to allow as a config option "whatever zone you boot up in" as well. But wait! I have found a work-around. I took a floppy, put a min macplus system on it, NCSA2.3Telnet (macTCP version), and MacTCP version 1.0.1 (from the distribution floppy, ie never before configured copy). I went in and clicked server, Class B, 8 bits of subnet, entered the IP address of a nameserver and clicked OK after having booted up on a MacPlus with it's LocalTalk connection physically pulled. IE, there was no zone name for it to save when I did the configuration. I then booted this floppy on a MacPlus in two different zones and was able to run and use Telnet. Previously when I'd done the same thing except I had used the pop-up list under the LocalTalk icon when configuring MacTCP to choose the current zone, it did NOT work when I went to the other zone (as Hanz complained about). This may stop working as soon as someone uses the control panel to bring up MacTCP AND uses the zonelist pop-up AND does not click cancel on the changes dialog when dismissing MacTCP. While AdminTCP lets you protect the second screen of config parameters, it does not protect the zone name. Perhaps if MacTCP was changed from type CDEV to INIT it would still work and no one could accidentally change this; I've already spent enough time experimenting on this to satisfy my curiosity. Hope this work-around helps! cmc