SUMMARY: Telnet problem

From: Ian Jones <ian_at_persimmon.com>
Date: Fri, 17 Feb 1995 09:09:08 -0500 (EST)

Original Problem:

> I have a telnet problem. A user is attempting to telnet
> in using Spry's "Internet in a Box" (sorry, I have no
> information on the telnet implementation there.) The dial-up
> account is via InterServ and SprintLink. A connection is
> made, but no login prompt ever appears. I can successfully
> telnet to OpenVMS and Ultrix machines, but not OSF/1.
>
> The problem also appears on port 80 (our WWW server) as
> well as 23. Running the CERN server code in debug mode
> shows an initial connection is made and name resolution
> is successful, the process forks (or so it claims) and
> then nothing happens. The client waits for ever for the
> transfer. The problem also exists with the NCSA server,
> but I haven't looked at any debug output yet.

I received three replies. Unfortunately none of the suggestions
fixed the problem. I include the replies below for those with
similar problems! Thanks to those who replied.

Ian.

-- 
Ian Jones    Persimmon IT, Inc.
ian_at_persimmon.com
-------------------------------------------------------
430 Cowper Street |        Suite 404, The Concourse
Palo Alto,        |        One Copley Parkway
CA 94301          |        Morrisville, NC 27560
USA               |        USA
-------------------------------------------------------
+1-919-481-1211 1-800-546-7242 (US) Fax +1-800-468-3747
Persimmon IT WWW server URL="http://www.persimmon.com/"
---
> Bob Wier, CS Dept., East Texas State University
> wier_at_bobcat.etsu.edu - keeper of the
> Ian - I'll be quite interested in any answers to this one - we are running
> a Dec Alpha 3000/600s with OSF/1 and telnet has always been very flakey.
> Sometimes it shows what you are describing. Sometimes the session starts
> off ok, but then progressively slows down until it takes 5 minutes to get a
> reponse back from a carriage return. They are all connected via ethernet,
> so modem problems and so forth are moot in this case.
> 
> What I've generally been doing is to make sure faculty here are running the
> latest version of NCSA (I think it's something like 2.308b). But there
> still seems to be a problem with the config.tel file. I just brougt up a
> 386 for a faculty member and again had the same problem with the connection
> being established, but no login prompt. I fixed that by trying a bunch of
> alternate configurations. If nothing else turns up that works for you, I
> could forward a copy of the config.tel file which seems to work here.
> 
> One suggestion - if your user also has NCSA ftp they might try that. The
> handshaking protocol seems a bit more robust. I've been able to proceed
> with ftp connections sometimes when telnet won't work from the same
> machine. NCSA says they are no longer doing development on PCtelnet - I
> assume they have shifted over to the windows version...
> 
---
From: anthony baxter <anthony.baxter_at_aaii.oz.au>
> Could it be an IP TOS problem, I wonder?
> 
> Create a file /etc/iptos with the line
> 
> telnet tcp 0x0
> 
> in it - this may help. (I remember there was a similar problem with some 
> Mac clients being unable to connect, this was the fix.)
> 
> The above line turns off IP Type-Of-Service for telnet - some clients
> may barf on it. If this is the problem, go and hit Spry over the head and 
> make them fix their client :)
> 
---
From: Peter Fogarty <syspjf_at_devetir.qld.gov.au>
> This looks identical to the problem we have been expiriencing with our
> OSF/1 V3 Alpha 2100's. TThe problem is the TCP/IP advertised window size.
> 
> Osf/1 defaults to a 32k advertised window size which some of our old
> terminal servers have a great deal of trouble with, in fact they hang on
> connection as you describe. The solution to this problem is to literally
> 'hack' your running kernel and change the values of the parameters
> 
> tcp_sendspace and tcp_recvspace to be 8k or 16k, which ever you equipment
> will handle. This is done by running dbx on the kernel as follows
> 
> 
>        # dbx -k /vmunix /dev/mem
>        (dbx) assign tcp_recvspace = 8192
>        (dbx) assign tcp_sendspace = 8192
>        (dbx) quit
>
> Then you will need to do an init 6 to cycle the tcp subsystem (well sort of).
> If you shutdown the running kernel completely, you will lose the change. So
> you will need to do this in oneof your statup files as well.
> 
> 
> Ahh, This sucks, I here you say. Correct. We have been yelling at DEC support
> for some months over this issue and they say that it is not a problem. You
> can not configure thee values in /sys/conf or anything like that, this is
> the only method of working around this at this stage. DEC support have offered
> to "write smething" for us but are threatening to charge Thousands of dollars
> because "OSF/1 isn't actually broken is it" so its not support.
---
From: Jon Howell <jonh_at_hitl.washington.edu>
> I had about the same problem with a Novell Lan Workplace for DOS client.
> The summary of the story is that the Novell client was a bit dated, and
> was still implementing TCP connections poorly, and so couldn't communicate
> with any OSF/1 machines, which insist on a stricter implementation.
> Upgrading the client software solved the problem. It sounds like Internet
> In A Box is a little poor.

Received on Fri Feb 17 1995 - 09:27:38 NZDT