makmur@athos.rutgers.edu (Hanz Makmur) (01/08/91)
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. The problem is, every time the students move from one zone or another, they have to configure their MacTCP using the control panel by choosing the zone there are in and reboot the Mac and then run their mactcp dependent programs. This is not acceptable to me since the Mac already know what zone it is in. I have read in the news that some one did it and I am trying to get the same result but fail. I cant figure out how it is done since macTCP is zone dependent. In other words, you move from one location to another, you have to reconfigure your MacTCP to that zone. All the Macs are behind ddp/ip gateway (Kbox)and their IPs are assigned dynamically. The MacTCP is set to SERVER. Any help you could provide will be appreciated. Thanks Hanz Makmur
hobson@elbereth.rutgers.edu (Kevin Hobson) (01/13/91)
In article <Jan.7.18.28.45.1991.9395@athos.rutgers.edu>, 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. The problem is, every time > the students move from one zone or another, they have to configure > their MacTCP using the control panel by choosing the zone there are in > and reboot the Mac and then run their mactcp dependent programs. This > is not acceptable to me since the Mac already know what zone it is in. You are assuming that it is zonename dependent. It is not. It is IP subnet and host number dependent. > I have read in the news that some one did it and I am trying to get > the same result but fail. I cant figure out how it is done since > macTCP is zone dependent. In other words, you move from one location to > another, you have to reconfigure your MacTCP to that zone. > 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. MacTCP is not appletalk zonename dependent but IP subnetted dependent since it is assigning an IP address based on the FastPath subnet address. You want MacTCP to take the dynamically assign IP address given by the particualar FastPath. Remember everytime an MacIntosh is power-up it is assign an appletalk address. The FastPath uses this address to assign an unused IP-address to that MacIntosh. At that point, MacTCP should take that address an use it. The applications need to talk to MacTCP to find out what is it particular IP-address. Applications should always be independent of zonenames and find out the zone they are now in and find the services it wants through appletalk by going to that particular zone. > 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. Your major problem will be with the gateway configuration in MacTCP since it assumes that the users are behind the same gateway everytime. If MacTCP could be set up to think that it is on one big IP network (arp for a address not on this subnet and let the cisco gateway "act" as the foreign host), then what you are trying to do in the Rutgers network will work. The way Rutgers network is set up, our cisco gateways proxy arp for addresses. How do you assign a gateway address in the form of 128.6.subnet.dynamically_assign_IP_address_of_macintosh when MacTCP has to know the IP address of the macintosh first? The FastPath software still does not know how the use a default-gateway option of the form 128.6.subnet.fastpath_host_address (arp on the particular subnet for different subnet hosts) Apple has to resolve this problem. You cannot get this to work. Sorry, Apple (and many other vendors) assume that TCP/IP networks that you should direct all "not this subnet" toward one gateway. What happens when this gateway goes away? These hosts do not know how to talk to other redundant gateways on that subnet because they are still configured for the old gateway. > 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. -- Kevin Hobson Internet: hobson@rutgers.edu Rutgers - The State University UUCP: {backbone}!rutgers!hobson P.O. Box 879, RUCS, Hill Center, Busch BITNET: hobson@{cancer,pisces}.BITNET Piscataway, N.J. 08855-0879 PHONE: (908) 932-4780
cmclark@terminator.cc.umich.edu (Charles Clark) (01/14/91)
In article <Jan.12.22.13.48.1991.21207@elbereth.rutgers.edu> hobson@elbereth.rutgers.edu (Kevin Hobson) writes: >In article <Jan.7.18.28.45.1991.9395@athos.rutgers.edu>, 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
makmur@paul.rutgers.edu (Hanz Makmur) (01/15/91)
In article <1991Jan14.064043.3618@terminator.cc.umich.edu> cmclark@terminator.cc.umich.edu (Charles Clark) writes: > .... > > 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). > You are a genius..I got two responds and my question is answered. I would have never guessed of this unless I have seen the code of MacTCP. YOU ARE RIGHT !!!. IT WORKS. Now my MacTCP is zone dependent. I guess Apple hides this feature. FYI: You dont really need an unused copy of MacTCP v1.01. Simply use resedit and open a resource 'ipln' offset 30 and type 00. This will set 'whatever' zone to nozone. > 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. > Yap, this is the way to do it. simply change the type from CDEV to INIT and your worry is over. > Hope this work-around helps! > > cmc This is definitely the solution. I am glad to have so many experts or beginners on the net who are willing to help each other. Thank you. Hanz Makmur Rutgers University
tom@wcc.oz.au (Tom Evans) (01/15/91)
In article <Jan.7.18.28.45.1991.9395@athos.rutgers.edu>, makmur@athos.rutgers.edu (Hanz Makmur) writes: > The problem is, every time > the students move from one zone or another, they have to configure > their MacTCP using the control panel by choosing the zone there are in > and reboot the Mac and then run their mactcp dependent programs. This > is not acceptable to me since the Mac already know what zone it is in. But MacTCP has to be told what zone the SERVER is in, that's the whole point. In your case there is a server in each zone - each kbox is acting as a server. There are multiple "solutions". Firstly, put all the student LocalTalk networks in the same zone. Secondly, disable IP in all your kboxes but one, and set that one up to have "Option 7" (check the manual) on. It will then be the one gateway for ALL MacTCP traffic, and will be in one zone. ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179