Ash + telnetd: telnet client hangs after exit
Ralf Friedl
Ralf.Friedl at online.de
Sun Oct 14 11:58:49 PDT 2007
Alexander Kriegisch wrote:
> BB 1.7.2 and many old versions down to 1.4.x, I don't know exactly.
> Platform: mipsel
>
> We have had this problem for months, maybe 1-2 years, with different BB
> versions, but now I think it is time to report it:
>
> On my embedded system there is BB running telnetd. The shell is ash. A
> client logs in and works until he types "exit". After that the session
> is terminated, but the telnet client hanngs waiting for - I don't know
> what. I can reproduce it with several telnet clients. It does not happen
> with Dropbear sshd, so I strongly assume it is a BB problem.
>
> Interestingly, the session exits cleanly if I call "setconsole -r"
> during the telnet session.
>
> Maybe somebody can find out what is wrong here. It might be a similar
> case to "ash endless loop after ssh client is killed" (April 20-29,
> 2007), I don't know.
>
> Regards
There are two possible conditions for a login server (telnetd,
SSH-Server, rlogin server, ...) to use as the end of the session:
1. The immediate child process (the shell) exits.
2. All child processes have closed the client side of the pty.
(The client closing the network connection is of course also causes the
end of the session, but that is not relevant here.)
busybox telnetd and the OpenSSH Server use variant 2, the dropbear
server uses variant 1.
There are reasons for both variants, so it is a matter of taste which
should be used.
With variant 2, the connection stays open as long as any child process
has the client pty open. It is possible to run "tail -f logfile & exit"
and leave the connection open until the program exits (in this case
never) or the client closes the connection. This may be annoying in case
it wasn't intended to leave a program running.
With variant 1, the connection is closed immediately after the shell exits.
With the OpenSSH Server, the connection may also be used to forward
other connections over the encrypted channel, this is not the case with
busybox telnetd.
I also tried the normal telnetd server on my Linux system, it also uses
variant 1, so probably busybox telnetd should do the same.
To do that, it would be necessary to catch SIGCHLD, which seems to be
left to default now. Then with the pid of the child, find the correct
session and shut it down.
The normal telnet server also just closes the ptmx instead of a SIGKILL
to the child process. The closing of the ptmx causes a SIGHUP, which
gives the shell the opportunity to a clean up and exit.
I think I could make a patch for this if it is determined that busybox
telnetd should be changed to do that.
Regards
Ralf Friedl
More information about the busybox
mailing list