#1366 closed defect (wontfix)

Telnet client resets connection with telnetd during long commands

Reported by: Gene Smith Owned by: Chris Johns
Priority: normal Milestone: 4.11
Component: network/legacy Version: 4.9
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description (last modified by Gedare Bloom)

Doing an "ls" command on a mounted SD or MMC card with 100's of files causes a "closed by foreign host" message to appear and the telnet client terminates.

The ENTER terminating character is sent to telnetd by the telnet client but telnetd never ACKs the transmission. Telnet client retries the transmission many times but eventually times out and sends RST. After a while, telnetd does send the response but it is too late and rejected. (So actually the connection is terminated or reset by the local host.)

So, other than the fact the the ls command is kind of slow or should respond incrementally, the real problem is due to telnetd running at the same priority as network task(s). It appears that the shell code doing ls, spawned by telnetd I think, is busy processing the request and can preempt tcp/ip from sending the ACK for the ENTER character which started the ls command. Telnet client times out before it see the ACK.

If the telnetd task is set to a priority less than network task priority, the ACK occurs immediately right before the ls command processing begins and telnet client remains happy during the wait and the data is send by telnetd and accepted and displayed.

I think this is a problem when default values are used for network and telnetd priority.

In telnetd.c function rtems_telnetd_initialize() I think the default priority needs to be set to one greater (actually lower) than network:

339: priority = rtems_bsdnet_config.network_task_priority + 1;

However, there is still a bit of a bug here too since, if network priority is default, its value at this point is still zero (the default user setting).

This needs to be fixed in rtems_glue.c in function rtems_bsdnet_newproc() where priority is set. After rtems_task_create() this line should be added:

637: rtems_bsdnet_config.network_task_priority = networkDaemonPriority;

Without this, the telnetd priority gets set to 1 (really high) but is immediately adjusted back to 100 (which is still the same as default for networking) so the problem persists.

Note: The .network_task_priority is used in ppp code at several places so this possible change could affect that code too. I don't use the ppp stuff.

I can provides a patch if this looks like a correct solution.

Change History (3)

comment:1 Changed on Aug 6, 2010 at 9:39:16 PM by Joel Sherrill

Component: miscnetworking
Milestone: 4.10Not Assigned
Owner: changed from Joel Sherrill to Eric Norum

Category -> networking
Resetting responsible party
Milestone -> not assigned

comment:2 Changed on Nov 20, 2014 at 4:38:02 AM by Chris Johns

Description: modified (diff)
Milestone: Not Assigned4.11
Owner: changed from Eric Norum to Chris Johns
Status: newaccepted

The only reason I can see for the ack not being sent back to the client, in fact any response at this lay in the stack not bring sent is something, ie the MMC driver, is taking all the resources. I have done a recursive ls on an NFS mount disk with hundreds of thousands of files using telnet and have not seen a problem. I have seen MMC drivers doing this with a polled serial port console as well.

I think this ticket should be closed.

comment:3 Changed on Dec 19, 2014 at 4:07:10 AM by Gedare Bloom

Description: modified (diff)
Resolution: wontfix
Status: acceptedclosed
Note: See TracTickets for help on using tickets.