id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,blockedby,blocking 1366,Telnet client resets connection with telnetd during long commands,Gene Smith,Chris Johns,"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.",defect,closed,normal,4.11,network/legacy,4.9,normal,wontfix,,,,