Question about telnetd in BusyBox

[Wåglund Oskar]

Hello everyone!

I have had an issue with inetd/telnetd in BusyBox the past couple of days which I can’t seem to get around and I was hoping for some friendly advice.

We have recently ported our product to use PetaLinux 2017.3 and with that BusyBox (version busybox-1.24.1), and everything has been going very well so far. Now, however, our customer has pointed out that sending telnet commands from their test framework to our product (which is running the BusyBox telnet daemon) does not work in their environment for commands longer than 56 characters. We have observed a “weird” behavior that telnetd will split up the echoed response to the client after 56 characters by adding “whitespace, carriage return” (ASCII 0x20, 0x0D) before continuing the output. This is illustrated in the attached WireShark log and screenshot. 10.40.241.50 is the telnetd server and 10.40.241.157 is the telnet client.

The result of this is that the Telnet client the customer is using in their test framework understands the response when the command entered was 56 characters or less long, but adds the entered command to the interpreted response when more characters are entered:

Connecting...

Sending:
Sending 56 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Received:
-sh: Sending: command not found

Disconnected


Connecting...

Sending:
Sending 57 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Received:
Sending 57 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
a
-sh: Sending: command not found

Disconnected

In the WireShark log you can also see that the Telnet negotiation begins with telnetd sending DO ECHO, to which the telnet client responds WON’T ECHO and later DON’T ECHO, but this has no effect it seems. I can see in a telnetd.c file in BusyBox that this seems to be the case, but I don’t have the option to recompile the code at the moment:

/* Make the telnet client understand we will echo characters so it
                      * should not do it locally. We don't tell the client to run linemode,
                      * because we want to handle line editing and tab completion and other
                      * stuff that requires char-by-char support. */
                      {
                                            static const char iacs_to_send[] ALIGN1 = {
                                                                 IAC, DO, TELOPT_ECHO,
                                                                 IAC, DO, TELOPT_NAWS,
                                                                 /* This requires telnetd.ctrlSQ.patch (incomplete) */
                                                                 /*IAC, DO, TELOPT_LFLOW,*/
                                                                 IAC, WILL, TELOPT_ECHO,
                                                                 IAC, WILL, TELOPT_SGA
                                            };

I have also seen a piece of code that seems related to the above mentioned problem but haven’t been able to connect the dots:

/* We map \r\n ==> \r for pragmatic reasons.
                                                                 * Many client implementations send \r\n when
                                                                 * the user hits the CarriageReturn key.
                                                                 * See RFC 1123 3.3.1 Telnet End-of-Line Convention.
                                                                 */
                                                                 if (c == '\r' && ptr < end && (*ptr == '\n' || *ptr == '\0'))
                                                                                       ptr++;
                                                                 continue;

Now my questions to you are


  1.  Is the added “0x20, 0x0D” a known issue/feature? (Maybe it is not the telnetd client adding it after all?)
  2.  Is there a way of disabling ECHO in telnetd somehow? I have tried desperately to configure this behavior through inetd.cfg and inetd.conf but to no avail so far.

I would be most grateful for any advice on this and I would also like to take the opportunity to thank you all for the great product that you have produced in BusyBox! 😊

Best regards
Oskar Wåglund


This e-mail may contain confidential and corporate proprietary information. If received in error, kindly notify us immediately and delete the communication from your system. Our contacts with you may further involve processing of personal data. Please read more about how and why ÅF processes personal data on our website www.afconsult.com<http://www.afconsult.com/sv/other-pages/privacy-statement/privacy-statement-for-externals/> .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191209/460a0023/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TelnetTest.png
Type: image/png
Size: 37460 bytes
Desc: TelnetTest.png
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191209/460a0023/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TelnetTest.pcapng
Type: application/octet-stream
Size: 5452 bytes
Desc: TelnetTest.pcapng
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191209/460a0023/attachment-0001.obj>