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
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox

Reply via email to