ALLIN1@aston.ac.UK (04/27/88)
Date: 27-Apr-1988 14:28 GMT Subject: problem with NCSA TELNET ? From: G Bellavia <BELLAVIAG@uk.ac.aston> Dept: Computer Science Tel No: 021 359 3611 X5289 TO: Remote Addressee ( _POST INFO-APPLETALK%EDU.CMU.ANDREW@ To all At Aston University UK.(dept of Computer Science) we have about 23 macs and a laserwriter connected on an appletalk(localtalk cabling) with a kinetics box connecting them to an ethernet network. We use NCSA Telnet 2.1 to log into our university machines e.g vaxes/vms sequent/unix etc. Inside the kinetics box we are running the udp.srec program. After many problems associated with noisy ethernets we have finally performed all modifications to the kinetics box. However one problem seems to remain. Whenever we launch NCSA Telnet for the first time on a mac it doesnt find the gateway. ie it gives network 0 when we do 'show network numbers'. After relaunching it usually gives network 3 which is correct. This behaviour is not consistent. Very occassionally it finds the gateway first time, sometimes it needs 3 or 4 relaunches to find it. At first I thought this was to do with the length of our appletalk (about 1100 ft) but the fastpath manager finds the gateway first time always. Also finding the laserwriter is no trouble unless some member of staff has disconnected his mac the wrong way! So what can the matter be. For info our kinetics box is on the end of the localtalk cable, the laserwriter in the middle. If there is anybody who has a similar problem or somebody who has any idea as to the cause please reply. yours Gino Bellavia Computer Officer Dept of Computer Science Aston University Birmingham B4 7ET England
CARRICK@IRLEARN.BITNET ("Kieran Carrick,UCD,Ireland") (04/28/88)
On the subject of Kinetics / NCSA We have a Kbox which we are using both to test NCSA TELNET and other IP product s and which we were also using with the AlisaTalk software. We offered our facilities to Apple for a demo and when we put all the bits back together the Alisatalk stuff refused to work while the NCSA Telnet stuff seems to work fine still. I suspect the Kbox but dont want to send it for repai r as I need it to continue testing TELNET applications and to evaluate TN3270 products. Has anyone any idea as to what could be wrong. I would like to understand how the IP stuff works and the Alisa stuff does not. Re-configuring the Kbox does not seem to effect the operation of the IP stuff but has not solved the Alisa problem. Any help greatly appreciated. (particularly from Apple people - after all it was all working before the Apple demo :-) ) Kieran Carrick Acknowledge-To: <CARRICK@IRLEARN>
kenw@noah.arc.CDN (Ken Wallewein) (04/28/88)
I'm not sure what's wrong with your NCSA TELNET, but it sounds a little like a problem we're having with ours. After some net reconfiguration and playing around with load files (we've been testing Pacer) we now find that NCSA Telnet 2.1 works on some Macs, and not on others. Here's the kicker: the Macs on which it works have power supplies with the +5 volts at 5.0 volts or BELOW. Those with the +5 much above this point do not work - and that includes most SEs, which tend to be around 5.1. Changing net configurations doesn't seem to have much effect. Another interesting tibit is that the older versions of Telnet work fine. I suspect that the new version is sending out a very short signal (how?!?), is doing few or no retries, is using an insuffucient time delay for K-box response, or such. We have a second K-box on order, and I'm looking forward to seeing what that does. Our current one is pretty old. Does anyone know of anyone using NCSA Telnet 2.1 on a non-Kinetics gateway? Sorry, I can't remember which load file we're running right now (and it's too late to drive to work to look :-), but it's CAP-compatible. It might well e udp.srec; that or something close. /kenw A L B E R T A Ken Wallewein R E S E A R C H kenw@noah.arc.cdn C O U N C I L
lui@oahu.cs.ucla.edu (Stephen Lui) (04/29/88)
Where do I get NCSA Telnet from? Stephen Lui ARPA: lui@cs.ucla.edu UUCP: ...!{cepu,ihnp4,trwspp,ucbvax}!ucla-cs!lui
bmh@demon.siemens-rtl (Beatrice M Hwong) (04/30/88)
In article <1385*kenw@noah.arc.cdn> you write: > > I'm not sure what's wrong with your NCSA TELNET, but it sounds a little >like a problem we're having with ours. > > After some net reconfiguration and playing around with load files (we've >been testing Pacer) we now find that NCSA Telnet 2.1 works on some Macs, and >not on others. Here's the kicker: the Macs on which it works have power >supplies with the +5 volts at 5.0 volts or BELOW. Those with the +5 much above >this point do not work - and that includes most SEs, which tend to be around >5.1. Changing net configurations doesn't seem to have much effect. > We, too, are using Pacer and find it conflicts with NCSA Telnet. The Pacer people say it is a Telnet problem-"not letting a socket go"? For us it is consistent across Telnet 1.12 and 1.2. We've temporarily given up using Telnet. The symptom is that when we attempt to use Telnet, we get "Appletalk listener error". Is that what happens to you? Beatrice Hwong Siemens RTL
gaige@ncsa.ncsa.uiuc.EDU (Gaige Paulsen) (05/01/88)
I don't know what Pacer is referring to, but I would like to answer a couple of the questions posed relative to the 2.1 version of NCSA Telnet for the Macintosh When NCSA Telnet terminates, it releases the AppleTalk port with which it is listening for IP packets (port 72 for those who care). If it didn't do this then you could not run NCSA Telnet, quit, and run NCSA Telnet again without getting the Appletalk Listener Installation error. As for giving up the socket, I believe that the offending programs are reversed, but I do not have much personal experience with pacer. To my knowledge, pacer installs a listener at boot time via an init which never gives up the socket which must be listened to for IP packets (hence the need to increase the system heap size in older versions of the software). NOTE: I am not certain about this for current versions and therefore this should not be taken as the final word, but it does correspond directly to the symptom of NCSA Telnet not being able to get the socket when Pacer has been used. By the way, NCSA Telnet does work with the CITI drivers which have a control panel entry with which the socket listener may be temporarily uninstalled (although CITI now provides a version of NCSA Telnet which has been modified to run directly over their drivers). I am very interrested in hearing any more comments on this subject as we are quickly nearing the 2.2 release of NCSA Telnet sometime early this summer. Thanks for your comments, Gaige B. Paulsen National Center for Supercomputing Applications Disclaimer, I don't need no stink'n disclaimer.......
terrell@musky2.MUSKINGUM.EDU (Roger Terrell) (05/02/88)
[] We have a small problem with NCSA Telnet 2.1 as well: Although it always connects fine (via k-box) to our VAX/VMS system, there are times when one tries to use FTP and the (CMU TCP/IP) FTP reports that it cannot connect to the given host. Most of the time it works fine. --Roger -- Roger Terrell ...musky2!terrell (UUCP) terrell@muskingum.edu (CSNet)