loganj@yvax.byu.edu (12/04/90)
We can't seem to get MacTCP 1.0.1 to connect to other domains through our Cisco router (the BYU domain is 128.187.x.x). We've tried MacTCP with NCSA Telnet, TN3270, and HyperFTP, and none of them can connect to anything other than BYU hosts (128.187.x.x). The same programs (Telnet & TN3270) connect properly to other domains with the non-MacTCP driver. This is not a "name service" problem, but a connection problem. The message from Telnet is "Host or Gateway not responding." We've specified the ip number of our Cisco router (128.187.1.3) in the "Gateway Address" box of the AdminTCP dialog, and our network mask is 255.255.0.0. Any suggestions? Is this a known problem? Sorry if this has already been discussed on the net. Thanks, jim loganj@yvax.byu.edu loganj@byuvax.bitnet
tony@scotty.dccs.upenn.edu (Anthony Olejnik) (12/05/90)
I, too, had a problem with MacTCP not being able to connect to host in other domains. It seems that even though I had a particular default gateway specified in MacTCP, it was listening to RIP packets and using that info instead of the specified address of the IP router. We use a single default IP Router as our default gateway and thus do not use RIP. All hosts on our campus should not be broadcasting RIP packets. However, some hosts were incorrectly configured and were broadcasting RIP packets. Usinging an ethernet monitor, it seems that the off campus (out of domain) ethernet address was *NOT* our default IP gateway. Rather it was the ethernet address of a host that was incorrectly sending RIP packets. When the MacTCP packet (destined for off campus) was received by the incorrectly configured host, it was discarded. --tony
garrett@brahms.udel.edu (Joel Garrett) (12/05/90)
In article <34032@netnews.upenn.edu> tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes: > >I, too, had a problem with MacTCP not being able to connect to host >in other domains. > >It seems that even though I had a particular default gateway >specified in MacTCP, it was listening to RIP packets and >using that info instead of the specified address of the IP router. I have been encountering similar problems on our local subnet. There is always some yahoo in the eng. college who just bought a new workstation and just plugs it in and turns it on without making sure things aren't configured correctly, especially the network stuff. Ok, in these peoples' defense, there is no official campus-wide policy (at least one that everyone knows about) about getting connected onto the various networks. At any rate, our local MacTCP host, which is running a beta-test version of BeaverGate, has been going a little crazy at inopportune times, and with the ai of an ethernet monitor, I was able to see the behaviour that Tony mentioned. For whatever reason, the MacTCP host was listening to (invalid) RIP packets that caused it to come up with a new default route which wouldn't forward any packets for the system, essentially killing it. Does anyone know of a way to keep MacTCP (1.01 is what I have) from listening to RIP packets? On our own local worstations, I have been able to maintain order by disabling RIP services on our local machines by commenting out the appropriate lines in the /etc/services file and not letting routed run on the systems (all we need is the default route to our ethernet's gateway onto the campus proteon backbone) Maybe someone's come up with a patch to mactcp or maybe the next version will address this? I agree that the bad RIP packets shouldn't be there in the first place, but I can't afford to have our MacTCP hosts go south every time somone else makes the same mistake (which they invariably do...), especially when the people are in another department, which makes it difficult for me to get the problem straightened out. (How would you feel if the you've been using your workstation for several weeks without evident problems, and someone calls you on the phone to tell you that it is set up wrong and needs to be corrected, especially someone from some other department that you've never heard of before, and not the campus communications people?) Please, if anyone has any additional info on this, please send me mail. I will post a summary of any info I receive. Thanks! Joel Garrett garrett@brahms.udel.edu