jpt@uh.msc.umn.edu (Joseph Thomas) (02/23/90)
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