krauskpf@uxe.cso.uiuc.edu (04/16/89)
From Tim Krauskopf at NCSA: I can speak for NCSA Telnet -- we have an EtherPort SE from Kinetics and I have tested it with NCSA Telnet. We run a huge Ethernet with IP routers and over 300 hosts, not to mention the connections across the campus backbone. I also have a IIx with an Apple EtherTalk board on my desk which I use with NCSA Telnet 8 hours per day. /* Written 3:36 pm Apr 13, 1989 by currier@prandtl.nas.nasa.gov in zaphod:comp.sys.mac */ /* ---------- "Mac Ethernet Interface" ---------- */ We have been having some ethernet problems on our network and some people have blamed(justified or not) the three Mac SE's we have. These SE's have Kinetic's ethercards. we also have a Mac IIx with a Apple ether board. On all the Macs we have both NCSA Telnet and The Stanford/MacIP. Because of these problems I was ordered to remove these applications from the Macs and stop using the network. I was hoping I could learn more about the Mac/ethernet interface, so here are some questions: 1) on a unix machine the is a process running all the time called in.routed and there is also a process in.telnetd. a) Do similar process run on the Mac? b) even when NCSA Telnet or MACIP are not running? The Unix process in.routed sends and receives routing updates. NCSA Telnet uses fixed routing so it does not send or receive this type of packet. in.telnetd is a "listen-only" process which waits for programs like NCSA Telnet to connect with it. NCSA Telnet does not listen for telnet connections, but it does listen for FTP connections -- ONLY when NCSA Telnet is running. 2) how is the Mac "seen" by the network when: a) the Mac is off? b) mac on but not in an application that uses ethernet? When the Mac is off, it might as well be disconnected. It is not capable of interacting with the net. When the Mac is sitting there in Finder, it is receiving packets, but not sending any. NOTE: if you have selected EtherTalk in the Control Panel's "Network" section, then the Mac will interact with the network with the AppleTalk protocols whenever it runs an application which prints or does anything with AppleTalk. TCP/IP, NCSA Telnet and MacIP have nothing to do with that. So I can't rule out a problem with these machines when the Mac is on, but I can rule out NCSA Telnet as being a contributor. I also can't rule out electrical problems, but Kinetics has sold a lot of these and I haven't heard anything from other sites about problems of that type. 3) There are NCSA Telnet and MACIP setup files in the system folder, do these affect the the network? For NCSA Telnet, the settings file contains about 100 bytes of configuration information - no executable code. It cannot affect the network. When NCSA Telnet is launched it initializes a listener for TCP/IP packets and when you Quit, the listener is removed according to the system requirements. I hope these questions are not too dumb, but in order for me to argue with my network managers, I need to know something about what is happening on the Macs. They don't Thanks -Jeff ---------------------------------------------------------- Jeff Currier (602)621-4948 Computational Fluid Mechanics Lab University of Arizona ---------------------------------------------------------- Ethernet is just coming into its own in a certain sense. Vendors are now starting to provide sophisticated tools which can analyze Ethernet traffic and determine where your problem is. There are several choices so there are no more excuses for network managers who don't take advantage of the tools which are available and choose to finger-point instead. Now if there is trouble while NCSA Telnet is RUNNING, now that's a different story. Let me know, or mail to telbug@ncsa.uiuc.edu to see if we can help. Tim Krauskopf NCSA
CALIFFM@BAYLOR.BITNET (Michael Califf) (04/21/89)
We had a similar problem with finger-pointing here at Baylor with a TCP/IP interface for our IBM mainframe. Turned out that the cause was the ether-to-channel interface on the IBM (NOT an IBM product) which had a fit every time it received a packet type it did not understand - like 809b. The problem was solved by using a pc program which allowed us to watch the ether packets and trace the culprit down. We haven't had any problems since, with 5 Mac II's running telnet almost all day on the ether and about 300 macs/Appletalk PC's internetted over our ether backbone. Mike Califf Communications Programming Coordinator Baylor University CALIFFM@BAYLOR.BITNET