[Toybox] PATCH telnetd

[김혜진]

Hi.

My real situation is like this :
1. running telnetd on embedded board.
2. running client on windows/linux
3. client works something on connection such as getting big file with tftp
or testing system with automated script for a long time.
4. client is killed abnormally, for example kill telnet process
5. At this time, telnetd goes infinite loop and cpu occupation almost
becomes 90%.

I think this connection should be closed completely and telnetd should
hold for next connection using select().
but select() returns 1, and it means a socket fd has some changes.
That is telnetd does not catch client already killed.

(Unfortunatly, PC running telnetd can't reproduce this issue. I recommended
to check any embedded board if you have)

As I know, It is abnormally disconnected network and should handle.
The only ambigous thing in the patch is the max fail count.
At first, set max fail count as 10, but it is not standard I think.

Thanks.


------------------------------------------------------------------------------------------------
Message: 5
Date: Tue, 17 Mar 2015 09:59:18 -0400
From: Rich Felker <dalias at libc.org>
To: toybox at lists.landley.net
Subject: Re: [Toybox] PATCH telnetd
Message-ID: <20150317135918.GY23507 at brightrain.aerifal.cx>
Content-Type: text/plain; charset=utf-8

On Tue, Mar 17, 2015 at 07:31:12PM +0900, ??? wrote:
> Hi. All
>
> I found an issue of telnetd that it loops infinitely when client
> disconnected abnormally on working.
> like client is killed by outside.
>
> On embedded system, this issue make that cpu occupation goes high.
>
> In this case :
> select() returns 1, means socket fd has something changes.
> but, read()/write() after select() gets an error because client already
> disconnected.

read does not return an error; it returns 0, indicating EOF.

> attached patch help prevent this issue.
> plz, check.

The patch as written does not seem correct. There is no justification
for killing the child process with SIGKILL; this is a very bad
practice and precludes any sort of cleanup it may need to do. Unless
it's specifically written not to, the child running in the telnet
session should automatically terminate when it loses its controlling
terminal, which should happen when the telnet session exits.

Can you clarify what exactly is going wrong for you?

Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150319/c58a8bce/attachment-0003.htm>