[RTEMS Project] #1366: Telnet client resets connection with telnetd during long commands

[RTEMS trac]

#1366: Telnet client resets connection with telnetd during long commands
------------------------+----------------------
 Reporter:  gene.smith  |       Owner:  chrisj
     Type:  defect      |      Status:  closed
 Priority:  normal      |   Milestone:  4.11
Component:  networking  |     Version:  4.9
 Severity:  normal      |  Resolution:  wontfix
 Keywords:              |
------------------------+----------------------
Changes (by gedare):

 * status:  accepted => closed
 * resolution:   => wontfix


Old description:

> 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.

New description:

 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.

--

--
Ticket URL: <http://devel.rtems.org/ticket/1366#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project