This summary has been a long time in coming. Unfortunately there
has been no real resolution. The only thing of worth that I
have gotten from CSC was that they had replicated the
problem but that they didn't think it mattered -- somehow the
reason behind the call was lost.
I have worked out some work-arounds to the problem and have determined
a bit more where the problem comes from with lynx.
First the original question:
---------- Original message ----------
Date: Fri, 31 Mar 1995 14:03:30 -0500 (EST)
From: Michael A. Crowley <mcrowley_at_mtholyoke.edu>
To: alpha-osf-managers_at_ornl.gov
Subject: lynx,LAT,NAS, 0 baud above 38400
Connecting by LAT to a machine running OSF 3.2 from Decserver 700s
running either NAS 1.1 or 1.5 sometimes results in a terminal speed
of zero. The servers this occurs with are those with modems
and which have the speed set to 57600. Coming in from other
servers set to 38400 results in the speed being 38400.
Connecting to an Ultrix machine from the 57600 servers, the speed
is listed as 38400.
Normally this speed setting doesn't matter. However, when it
is set to zero, the screen handling of "lynx" does not work
correctly. "stty 38400" does not help; something in lynx sets
it back to zero. vi is also a problem because it sets a window
size as if you were on a low speed line. That can be worked around
by setting "wi" manually.
... my questions deleted ...
------------------------------------------------------------------------------
The last CSC response I received was:
> Date: Tue, 16 May 1995 13:24:31 -0600
> To: mcrowley_at_mhc.mtholyoke.edu
> Subject: C950412-1557
>
> Mike,
>
> Speed does not matter. I worked this call in lab With John Wieland
>
> setting the terminal server port to 57.6 it logs in okay
> but stty shows speed as 0
>
> Since the terminal server talks at 10 megabits per second it does
> not matter what the port speed it set at. It will communicate
> at the fastest speed possible.
>
> We set the stty speed to all different speeds but it did not matter
> or change the baud rate.
>
------------------------------------------------------------------------------
They replicated the conditions but had lost the original
problem that this produced. Having stty showing speed as zero
does cause problems:
1. vi
The window is set as if you were on a slow line.
Workaround: set wi parameter
setenv EXINIT 'set ic ai redraw wm=0 nowrapscan wi=200'
2. lynx and curses
The problem here is that lynx uses curses, and curses
(or cursesX on Ultrix) seems to have a problem
when the speed is set to zero whether it's
Ultrix or Digital UNIX. For a small example program
where this occurs, see:
ftp://mhc.mtholyoke.edu/pub/system/curses/cstty.c
Workaround: ncurses
ftp ftp.netcom.com # pub/zmbenhl/ncurses
By compiling lynx using ncurses, the problem does
not occur and lynx is usable.
3. pppd (
ftp://dcssoft.anu.edu.au/pub/ppp)
Will not work at speed==0.
Workaround: put some speed on the command line: pppd 38400
Given that there are popular programs out there that check the speed,
it is not the case that the speed zero doesn't matter. It has
a severe indirect effect. I'm not going to try and reopen my
CSC call, but I do hope this problem will be made to go away in
an upcoming release of Digital Unix.
Mike
---------------------------------------------------------------------
Michael A. Crowley mcrowley_at_mtholyoke.edu
Director of Network and Technical Services 413-538-2140
Mount Holyoke College, Dwight Hall fax: 413-538-2331
50 College St, South Hadley, MA 01075
Received on Tue Jul 18 1995 - 03:19:41 NZST