paisley@mte.ncsu.edu (01/01/91)
We are reconfiguring our lab from using built-in TCP drivers (like NCSA Telnet) to using MacTCP. I had no problems with systems directly on the Ethernet, but can't get it to work on machines that are on LocalTalk and then connected to the big net via a FastPath. I don't have any real documentation on MacTCP since the MacTCP drivers came included in other packages (like Mathematica, etc.). I think I've tried most combinations of options. System I'm trying to get this to work on at present: Mac II ci w/ 8Meg and Apple 2 page display running on 8.24 card System 6.0.7 under Multifinder Various INITs including Responder, Public Folder, etc. Mike Paisley Paisley@mte.ncsu.edu Paisley@ncsumte (BITNET)
frye@cerl.uiuc.edu (G. David Frye) (01/01/91)
In article <1990Dec31.173427.8371@ncsuvx.ncsu.edu> Paisley@mte.ncsu.edu writes: >We are reconfiguring our lab from using built-in TCP drivers (like NCSA Telnet) >to using MacTCP. I had no problems with systems directly on the Ethernet, but >can't get it to work on machines that are on LocalTalk and then connected to >the big net via a FastPath. I don't have any real documentation on MacTCP >since the MacTCP drivers came included in other packages (like Mathematica, >etc.). Remember that non-MacTCP NCSA Telnet worked in this configuration. That may help get you through the frustrating exercise of getting MacTCP to work. I had the same problem -- changed software versions, installed MacTCP, didn't have any documentation. You know that the hardware and the gateway software worked before you started. Keep it in mind. The one key piece was knowing to configure MacTCP to be in "server" mode. It seems intuitive to use the "dynamic" setting, but it's wrong and you'll get inconsistent results at best. You also need to know the address of your gateway to the outside world. Note that "Gateway address" is NOT the IP address of the Fastpath, but rather of the gateway from the Ethernet LAN to the Internet. This only applies if you are specifying IP addresses that aren't on your LAN. One subtlety that I didn't realize until I was told by someone at NCSA -- their Telnet program does not use the MacTCP Hosts file. The Telnet config file is still needed and is used to reference host names and god knows what else. Finally, you need to reboot the Mac after _every_ change to MacTCP. G. David Frye ----------------------------------------------------------------------------- INTERNET: frye@cerl.uiuc.edu PLATO: frye / s / cerl PHONE: (217) 333-7439 -----------------------------------------------------------------------------
paisley@mte.ncsu.edu (Mike Paisley) (01/01/91)
In article <1990Dec31.214828.20984@ux1.cso.uiuc.edu> frye@cerl.uiuc.edu (G. David Frye) writes: >In article <1990Dec31.173427.8371@ncsuvx.ncsu.edu> Paisley@mte.ncsu.edu writes: >>We are reconfiguring our lab from using built-in TCP drivers (like NCSA Telnet) >>to using MacTCP. I had no problems with systems directly on the Ethernet, but >>can't get it to work on machines that are on LocalTalk and then connected to >>the big net via a FastPath. I don't have any real documentation on MacTCP >>since the MacTCP drivers came included in other packages (like Mathematica, >>etc.). >... >The one key piece was knowing to configure MacTCP to be in "server" mode. It >seems intuitive to use the "dynamic" setting, but it's wrong and you'll get >inconsistent results at best. We have our net setup for manually entering the net numbers, but I tried "server" mode as well, to no avail. I also checked a few more things. I booted with no INITs loaded (except MacTCP) and that didn't help. I tried selecting LocalTalk interface instead of EthernetTCP in the MacTCP CDEV. Finally, I checked out the version number and am using MacTCP v1.0. I'm not sure what to try next. Mike Paisley (paisley@mte.ncsu.edu) PAISLEY@NCSUMTE (BITNET) (919) 737-7781
mst@ms.secs.csun.edu (Mike Temkin) (01/02/91)
In article <1991Jan1.001629.15224@ncsuvx.ncsu.edu> paisley@mte.ncsu.edu (Mike Paisley) writes: >We have our net setup for manually entering the net numbers, but I tried >"server" >mode as well, to no avail. I also checked a few more things. I booted with no >INITs loaded (except MacTCP) and that didn't help. I tried selecting LocalTalk >interface instead of EthernetTCP in the MacTCP CDEV. Finally, I checked out the >version number and am using MacTCP v1.0. I'm not sure what to try next. > >Mike Paisley (paisley@mte.ncsu.edu) >PAISLEY@NCSUMTE (BITNET) (919) 737-7781 First of all, what type of gateway are you using (FastPath, GatorBox, Apple Internet Router,...)? What is the IP address, netmask and class of the gateway? Is the gateway setup to do IP subnetting (subsectioning) or not? Please give all the information you can so we know what is going on. Thanks, Mike. -- Mike Temkin mst@csun.edu Cal. State U. Northridge, School of Engineering and Computer Science Voice phone: (818) 885-3919
paisley@mte.ncsu.edu (Mike Paisley) (01/03/91)
In response to helpful requests for more information, I will summarize my entire setup. I am trying to get NCSA Telnet with MacTCP drivers to run in an environment where previously NCSA Telnet with internal drivers worked perfectly. Local Environment: Mac IIci w/ 8M RAM and Apple 2 page display on 8.24 card MacTCP version 1.0 IP number 128.109.161.42 on class B network entered as either: Net:32877, Subnet:161, Node:42 or Net:32877, Subnet:1289, Node:10 Selected on separate occations either LocalTalk or Ethernet(TCP) connections in the MacTCP CDEV. I also tried Net:32877,Node:41258 so that I got mask 255.255.0.0 as suggested by David (djh@cs.mu.OZ.AU) to be necessary for v1.0 MacTCP, but it still didn't work. Network Environment: Kinetics FastPath 3 running KFPS code v1.0 with subnet routing on and option 1 (no RARP). Network: 16 bits (128.109 = 32877) Subnet: 11 bits (161.32 = 1289) Thus I have reserved host numbers .32 through .63 for machines on the FastPath. We use explicit IP numbers, which I assign to each machine, making sure that they are unique and fall in the proper range. Appletalk Side Ethernet Side ============== ============= IP#:128.109.161.63 IP#:128.109.161.21 Net#: 1289 Net#: 161 Zone: MTE-Res.Bldg.#1 Zone:Backbone161 I also have the default gateway set as 128.109.161.221 and RARP options turned off. Internet Environment: Cisco Router separating 161 from rest of the campus internet. I don't know anything else about how it is configured, except it also routes our AppleTalk packets just fine. Thanks again for all of the good suggestions recieved so far. Mike Paisley (919) 737-7781 Paisley@mte.ncsu.edu paisley@ncsumte (BITNET)
kdb@macaw.intercon.com (Kurt Baumann) (01/04/91)
In article <1991Jan3.000106.19583@ncsuvx.ncsu.edu>, paisley@mte.ncsu.edu (Mike Paisley) writes: > MacTCP version 1.0 You might want to try a later version of MacTCP they are up to 1.0.1 at the moment. Also is any experiencing these kinds of problems with software other than XCMD's and NCSA using MacTCP? Such as our product, TCP/Connect II or Wollongong's? I'm curious, becuase we haven't had any reported problems... -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
paisley@mte.ncsu.edu (Mike Paisley) (01/04/91)
In article <278368CB.4E9F@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes: >You might want to try a later version of MacTCP they are up to 1.0.1 at the >moment. Silly us (NCSU), since we have a site license, our campus computing center thought we would automaticaly get updates. So we're working on this one right now. >Also is any experiencing these kinds of problems with software other than >XCMD's and NCSA using MacTCP? Such as our product, TCP/Connect II or Wollongong's? We have a user here with TCP/Connect and it does the same thing. >I'm curious, becuase we haven't had any reported problems... > >-- >Kurt Baumann InterCon Systems Corporation >703.709.9890 Creators of fine TCP/IP products >703.709.9896 FAX for the Macintosh. After more hunting and pecking, I found that the dynamic addressing is working correctly as well. Finally, Randy Thomas (rjt@sedist.cray.com) pointed out that the FastPath needed to create an object with name of the IP number of the box on the AppleTalk side and of type IPADDRESS. I checked, and my machine was creating an IPADDRESS object for itself, but there was no IPADDRESS object from the FastPath. Thus, this seems the most likely culprit. He's running gateway code KSTAR that came with his FastPath 4. I'm running the code that came with my PROM upgrade (3.0), is this KSTAR? Any ideas where to get KSTAR code that is still compatible with a FP-3? Thanks. Mike Paisley (919) 737-7781 paisley@mte.ncsu.edu PAISLEY@NCSUMTE.BITNET
garrett@brahms.udel.edu (Joel Garrett) (01/04/91)
In article <1991Jan3.225522.21430@ncsuvx.ncsu.edu> paisley@mte.ncsu.edu (Mike Paisley) writes: >the FastPath. Thus, this seems the most likely culprit. He's running gateway >code KSTAR that came with his FastPath 4. I'm running the code that came with >my PROM upgrade (3.0), is this KSTAR? Any ideas where to get KSTAR code that >is still compatible with a FP-3? Thanks. There was someone out on the net that said something to the effect that there was a way to patch MacTCP to work with non-KIP-style routers (ie KFPS-2 & 3s) I sent a note to the guy, but never heard anything back from him. According to Shiva (the new keepers of FastPath technology) the only solution available is to upgrade your boxes to KFPS-4s for $999 or run KIP if you have a Sun or other atalkad-capable machines (does anyone know of a list of atalkad-capable systems? We don't have any Suns on our local network (but we do have a few Iris 4Ds and a few other equally un-BSDish machines such as HP9000s and old Iris 3130s and we've never had any luck bringing up atalkad on any of these hosts without what looked to be more work than we were willing to handle...) Can anyone else shed some more light on this matter? Thanks! > >Mike Paisley (919) 737-7781 >paisley@mte.ncsu.edu >PAISLEY@NCSUMTE.BITNET
lim@slc6.INS.CWRU.Edu (Hock Koon Lim) (01/04/91)
In article <278368CB.4E9F@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes: > >You might want to try a later version of MacTCP they are up to 1.0.1 at the >moment. > >Also is any experiencing these kinds of problems with software other than >XCMD's and NCSA using MacTCP? Such as our product, TCP/Connect II or Wollongong's? > >I'm curious, becuase we haven't had any reported problems... > I have came across some problems running MacTCP v1.1. The Mac is connected to the campus ethernet with an ethernet Interface. MacTCP is install for application like Stanford Mac/IP V4.0. The address assignment for the Mac is provided by a bootp server running CMU`s bootpd. The MacTCP is configured to get the address from "server". When I start the Mac/IP, the mac send out the BOOTP Request to the network. It received a BOOTP Reply from the server. In the reply packet, it get its IP address and the Gateway address which is set to the Bootp server address(this work find if the Mac is on the LocalTalk but not on the ethernet). I have to enter the default gatway address in the MacTCP configuration. After the Mac get the BOOTP Reply, it will send out an ICMP C Get address mask packet. This packet will cause some problem on the network. Now all the IP hosts on the network will try to reply the Address mask request. If the Mac is not in the IP hosts ARP table, they will also send an ARP request packet packet for this mac. Every IP hosts will send the ICMP R Address mask = [255.255.0.0] to this poor Mac. So my question is why the Mac has to send out the Get address mask packet? Is they any MacTCP configuration I did wrong to cause this problem? The following is the Caputure file from the sniffer which so this problem. Thanks, Hock-Koon Lim, Information Network services Case Western Reserve University; Cleveland, Ohio, USA 44106 (216) 368-2982 lim@ins.cwru.edu ----------------------------------------------------------------- Sniffer Network Analyzer data from 27-Dec-90 at 10:51:42, file C:\CAPTURE\MACTCP.ENC, Page 1 SUMMARY Delta T Destination Source Summary 42 3.9915 Broadcast Mac-Test BOOTP Request 43 0.0084 Mac-Test U-B 030A36 BOOTP Reply 44 0.0012 Broadcast Mac-Test ICMP C Get address mask 45 0.0004 Mac-Test Sun 09FA67 ICMP R Address mask = [255.255.0.0] 46 0.0004 Mac-Test Sun 02A20E ICMP R Address mask = [255.255.0.0] 47 0.0001 Mac-Test Sun 02AB5C ICMP R Address mask = [255.255.0.0] 48 0.0004 Mac-Test Sun 02A2AF ICMP R Address mask = [255.255.0.0] 49 0.0003 Mac-Test Sun 02A1D9 ICMP R Address mask = [255.255.0.0] 50 0.0004 Mac-Test U-B 03091E ICMP R Address mask = [255.255.0.0] 51 0.0003 Mac-Test U-B 030A2B ICMP R Address mask = [255.255.0.0] 52 0.0005 Mac-Test Sun 0A04F0 ICMP R Address mask = [255.255.0.0] 53 0.0002 Mac-Test Sun 095BBA ICMP R Address mask = [255.255.0.0] 54 0.0005 Mac-Test Sun 095BCD ICMP R Address mask = [255.255.0.0] 55 0.0002 Mac-Test Sun 02974C ICMP R Address mask = [255.255.0.0] 56 0.0005 Mac-Test DEC 1AFD82 ICMP R Address mask = [255.255.0.0] 57 0.0003 Mac-Test U-B 030AB2 ICMP R Address mask = [255.255.0.0] 58 0.0006 Mac-Test U-B 0308D6 ICMP R Address mask = [255.255.0.0] delete a lot of ICMP reply for Address mask here 189 0.0001 Broadcast DECnet000BA4 ARP C PA=[129.22.8.87] PRO=IP 204 0.0002 Broadcast DECnet000BA4 ARP C PA=[129.22.8.87] PRO=IP 205 0.0001 Broadcast DECnet000BA4 ARP C PA=[129.22.8.87] PRO=IP 206 0.0002 DECnet000BA4 Mac-Test ARP R PA=[129.22.8.87] HA=00001D00DB99 PRO=IP 207 0.0029 Broadcast Mac-Test ARP C PA=[129.22.8.87] PRO=IP 208 0.0004 Mac-Test Sun 02A0C5 ICMP R Address mask = [255.255.0.0] 209 0.0011 Mac-Test DECnet000BA4 ICMP R Address mask = [255.255.0.0] 210 0.0019 Mac-Test DECnet002FA4 ICMP R Address mask = [255.255.0.0] -- Hock-Koon Lim, Information Network services Case Western Reserve University; Cleveland, Ohio, USA 44106 (216) 368-2982 lim@ins.cwru.edu
dd@ariel.unm.edu (Don Doerner) (01/06/91)
In article <17219@brahms.udel.edu> garrett@brahms.udel.edu (Joel Garrett) writes: >>the FastPath. Thus, this seems the most >>likely culprit. He's running gateway >>code KSTAR that came with his FastPath 4. >>I'm running the code that came with >>my PROM upgrade (3.0), is this KSTAR? >>Any ideas where to get KSTAR code that >>is still compatible with a FP-3? Thanks. > There was someone out on the net that said > something to the effect that there > was a way to patch MacTCP to work with > non-KIP-style routers (ie KFPS-2 & 3s) > I sent a note to the guy, but never > heard anything back from him. According to > Shiva (the new keepers of FastPath > technology) the only solution available is > to upgrade your boxes to KFPS-4s for $999 > or run KIP if you have a Sun or other > atalkad-capable machines (does anyone > know of a list of atalkad-capable systems? > We don't have any Suns on our local network > (but we do have a few Iris 4Ds and > a few other equally un-BSDish machines > such as HP9000s and old Iris 3130s and > we've never had any luck bringing up > atalkad on any of these hosts without > what looked to be more work than we were > willing to handle...) > Can anyone else shed some more light on this matter? Maybe. The PROM code in all FastPaths is really silent (also robust, also stupid) router code, with a minimum of functionality. In particular, the PROM code in all FastPaths will support the static addressing mode of MacTCP, or any other piece of TCP/IP code (e.g. NCSA Telnet), *but* *will* *not* support the server mode of MacTCP (a.k.a. the "dynamic" mode of NCSA telnet), wherein the driver solicits an available IP address from the Kinetics box. The PROM code in the Kinetics box just simply does not have the smarts to perform this function. So, if you *must* run the PROM code for some reason, you *must* use static addressing. Kinetics' (now Shiva's) KSTAR code was originally based upon some code called 'KIP' which was developed, and is still available, at Berkeley (I think you can FTP anon to berkeley.edu and get to the right machine - hunt around, and if you can't find it mail me, I will try to conjure up a better location hint). KSTAR does lots of things that KIP does not do - DECNET encapsulation, ... ad nauseum. However, if you can't run the KSTAR code, I believe you can run the KIP code on FastPaths 2 and 3 (but I am not going to bet anything I really care about on that). And I believe it *does* support MacTCP server style address allocation. BTW, MacTCP dynamic address allocation is an algorithm for assigning an IP address on the basis of the AppleTalk address for the node, and is basically useless except in an isolated collection of Ethernetted Macs, as far as I can figure... Also, I believe that the single largest bug in the MacTCP 1.0.0 code was a complete failure to support SCSI Ethernet interfaces (MacTCP 1.0.1 is only marginally better). Point being that I am not sure that it is imperative for you to upgrade your MacTCP unless you anticipate using it w/ SCSI E'net interfaces... Anyway, that's about all I know about this situation - but I will be happy to help answer e-mail queries. We are running KFPS4s+KSTAR, PhoneNet, Ethernet, MacTCP, and a small army of applications (including the hypercard stack that I am using to respond to this posting!) successfully. I can look up any facet of what we are doing, and let you know... Don Doerner, Communication Manager University of New Mexico CIRT
paisley@mte.ncsu.edu (Mike Paisley) (01/08/91)
In article <1991Jan3.225522.21430@ncsuvx.ncsu.edu> paisley@mte.ncsu.edu (Mike Paisley) writes: > >After more hunting and pecking, I found that the dynamic addressing is working >correctly as well. Finally, Randy Thomas (rjt@sedist.cray.com) pointed out >that the FastPath needed to create an object with name of the IP number of the >box on the AppleTalk side and of type IPADDRESS. I checked, and my machine was >creating an IPADDRESS object for itself, but there was no IPADDRESS object from >the FastPath. Thus, this seems the most likely culprit. He's running gateway >code KSTAR that came with his FastPath 4. I'm running the code that came with >my PROM upgrade (3.0), is this KSTAR? Any ideas where to get KSTAR code that >is still compatible with a FP-3? Thanks. Last Update on this topic: I got a call from the person at Apple who wrote MacTCP (sorry, I forgot your name), and he confirmed that the IPADDRESS object was required for MacTCP to work correctly. Wow, I was impressed with Apple's service on this one. I called Shiva to see if they had any older KSTAR code that would work on a FP3, and they said that KSTAR 8.0, Manager 5.1 (both for FP4's) was all they supported and noone at Novell (according to them) would actively keep any of that stuff either. Well, I guess its time I upgraded to a FP4, but it will take time for me to beat a $1000 out of people for the upgrade, so if anyone has a copy of the last KSTAR code that ran on a FP3, I'd appreciate hearing from you. Thanks to all the many people for helping me out with this one. Mike Paisley (919) 737-7781 paisley@mte.ncsu.edu PAISLEY@NCSUMTE.BITNET
moyman@ECN.PURDUE.EDU (James M Moya) (01/08/91)
> >Last Update on this topic: I got a call from the person at Apple who wrote >MacTCP (sorry, I forgot your name), and he confirmed that the IPADDRESS object >was required for MacTCP to work correctly. Wow, I was impressed with Apple's >service on this one. > This just isn't entirely true. FastPath 1's, 2's, and 3's ran KIP (not KSTAR) and never registered an IPADDRESS node for themselves. They registered themselves as IPGATEWAY (FP4's running KSTAR register themselves as IPADDRESS) ...and MacTCP ran fine (and still does...)... through them. --moya --Mike Moya --Macintosh Systems and Networking --Engineering Computer Network, Purdue University --moyman@ecn.purdue.edu or ..!pur-ee!moyman
paisley@mte.ncsu.edu (01/09/91)
In article <9101081328.AA11082@aquarium.ecn.purdue.edu> moyman@ECN.PURDUE.EDU (James M Moya) writes: >> >>Last Update on this topic: I got a call from the person at Apple who wrote >>MacTCP (sorry, I forgot your name), and he confirmed that the IPADDRESS object >>was required for MacTCP to work correctly. Wow, I was impressed with Apple's >>service on this one. >> >This just isn't entirely true. FastPath 1's, 2's, and 3's ran KIP (not >KSTAR) and never registered an IPADDRESS node for themselves. They >registered themselves as IPGATEWAY (FP4's running KSTAR register themselves >as IPADDRESS) ...and MacTCP ran fine (and still does...)... through them. >--moya > >--Mike Moya >--Macintosh Systems and Networking >--Engineering Computer Network, Purdue University >--moyman@ecn.purdue.edu or ..!pur-ee!moyman > I think GatorBoxes also register IPGATEWAY nodes, if I'm not mistaken. However, in my case the FP3 isn't registering any IP node on the net, so it just don't work for me. Thanks for clarifying that. Mike Paisley paisley@mte.ncsu.edu PAISLEY@NCSUMTE.BITNET (919) 737-7781