Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request
From: rcodi@koel.co.rmit.oz.au (Ian Donaldson)
Newsgroups: comp.sys.sun
Subject: Re: SunOS 4.0.3 telnet problems
Keywords: SunOS
Message-ID: <5307@brazos.Rice.edu>
Date: 26 Feb 90 13:05:52 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 36
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n46, Replies: v9n61
X-Sun-Spots-Digest: Volume 9, Issue 53, message 10

medin@cincsac.arc.nasa.gov (Milo S. Medin) writes:

>I don't think your problem is in in.telnetd.  We had the same problem
>here.  It turned out to be /bin/login hanging.   ...

>The cause is that inetd was manually restarted from a shell, and thus
>inherited the environment of it's parent process.  It's this environment
>that causes things to wedge, 

I found this problem under 4.0.3 too, and found that there were at least
two problems.

When I ported 4.3-tahoe version of /bin/login to SunOS 4.0.3 to see what
was going on, I found that the environment was being stomped on.  I did a
"w" and found my encrypted passwd in the output!

The solution was to initialize the variable "envinit" inside "login.c" to
prevent setenv() from stomping randomly on memory.

ie:
	char *envinit[] = {0};

Without this, anything could happen to /bin/login.  It could hang, crash
or anything, and would be influenced by the size of the environment or the
number of arguments it was passwd by its invoker (eg: inetd).  If inetd
was restarted from a shell then this size would differ, producing
different results.

HOWEVER, replacing /bin/login under 4.0.3 didn't cure the telnet problem.
Compiling up a stock 4.3-tahoe telnetd and installing it *did* fix the
problem, instantly.  I reverted to the 4.0.3 /bin/login once telnetd was
replaced and it still worked ok (so far).

(Incidently, it was a Sun 3/80, running 4.0.3 EXPORT)

Ian D