[comp.protocols.appletalk] problem with NCSA TELNET ?

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)