> Got 5.0.2 on a new HP Netserver LH Pro. An odd behavior, is that an "ls"
> on any telnet session from any terminal other than the console will lockup
> the telnet or rlogin session. No line feed, nuthin, although you can quit
> the Telnet session after a CTRL-[.
What does "any terminal other than the console" mean? If it actually
means "any of our Windows desktops that are all running the same Windows
telnet client", you may be looking at a client bug.
Quote:> lc, lx, or l all work fine, just ls. Also saw this behavior on the
> Progress Database server startup command.
It's going to be some sort of flow control problem. To demonstrate, do
this:
$ ls > junk
$ cat junk
You should see the same lockup.
Quote:> Are there some mandatory patches needed on a 5.0.2 system?
No, but there's a recommended networking patch, recently issued.
oss449a fixes lots of TCP and NFS problems.
Meanwhile, you need to do a bit of research. What kind of network card
and driver are you using? Is it SCO-supplied? If not, is it an LLI or
MDI driver? If it's an LLI driver (same Driver.o would work on ODT
3.0?), you may need to set a kernel parameter, STRMAXBLK, to 4096.
Technical Article http://www.sco.com/cgi-bin/ssl_reference?640379
mentions this (in the context of a different problem).
If you *can* duplicate the problem from another Unix system, it might be
interesting to look at the state of the telnet client, using crash(ADM)
oir the equivalent. What does its kernel stack look like? What event
is it waiting on? What about the telnetd on the SCO system? In what
state are the sockets (run `netstat`). Other useful tools include lsof
(ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/) and the "Network/Security
Tools" TLS (tls604) on ftp://ftp.sco.com/TLS/, tools "sockinfo", "ss",
and possibly "tcpdump".
Quote:>Bela<
by