🚀 go-pugleaf

In Volume 9, Issue 46, Mark writes:
> 
> Every so often, no one can telnet into these machines.  You get a
> "connected to ..." message, but you never get a login: prompt.  The only
> way to fix this problem is to do a reboot of the entire system.  After
> this, you can telnet in fine!

We too have experienced this problem on our 4/280 running 4.0.3. When
looking into the problem, we found the following:

(If you have source code, or get access to the Berkeley code, look at
in.telnetd.c )

In the main loop ( telnet(f,p) ), the server requests to remote echo and
to suppress go ahead ( TELOPT_ECHO and TELOPT_SGA ) via its dooption()
routine.

dooption() for TELOPT_ECHO will attempt to change the tty modes to turn on
ECHO and CRMOD via a mode() call.

mode() flushes output to the terminal, gets the current settings
(TIOCGETP), sets the flags, and TRIES to set the new settings (TIOCSETP).

One will find (either with source code debugging, or grabbing a core
image, which isn't much help since everything is striped ), the in.telnetd
hangs on the ioctl(pty,TIOCSETP,&b). We've "fixed" this problem quick and
dirty by skiping the dooption(TELOPT_ECHO). This has not yet had an
adverse effect, but it should only be a matter of time. One of these days,
someone will try telnet'ing to our machine from something that's not as
well behaved as what we currently run.

We've looked very briefly into what was happening, and haven't uncovered
anything yet. The previous modes of the tty are the same for a working and
a non-working state, meaning the problem is somewhat deeper in the kernel.
If someone can readily duplicate this, we'd be more than happy to try and
find the "right" fix. Hope this sheds some light.

Joseph Thomas				E/Mail:	 jpt@msc.umn.edu
Minnesota Supercomputer Center 		AT&T:    +1 612 626 0277
Minneapolis, MN  			FAX:     +1 612 624 6550