Why garbage characters are displayed in OS X telnet

[stevebow]

QNAP, I believe I have discovered why, when you telnet into a NAS via the OS X Terminal, garbage characters are displayed. See http://forum.qnap.com/viewtopic.php?f=129&t=6936

Unfortunately, it appears to be a QNAP bug.

The problem happens when the ~/.profile file is run during login, which contains the reset command to reset the OS X terminal. When the reset command is issued, the following escape sequences are sent to the terminal:

1b631b284b1b5b4a1b5b306d1b5b3f323568

which, when translated to something more meaningful, yields:

Code: Select all

<ESC>c
<ESC>(K
<ESC>[J
<ESC>[0m
<ESC>[?25h

Take note of the second sequence, this is the one that screws the characters in the OS X terminal. This is not a defined sequence in the ANSI control sequence (the non-defined sequence may be screwing the OS X terminal emulator?) and is very likely a typo. My guess is that it should be <ESC>[K (note the square bracket).

The last sequence is a private DEC sequence and was not introduced until VT300, yet it is sent for any type of OS X terminal emulation. It probably should not be there at all.

OS X Terminal allows you to use any of 8 emulations (Preferences->Advanced->Emulation). It doesn't matter which emulation I choose, the same escape sequences are used, which makes be wonder if the string is compiled into BusyBox. I can't seem to find any termcap/terminfo files, which backs up this theory.

A quick howto:

Telnet into the NAS via OS X Terminal. After login, the terminal clears and the first thing you will notice is the strange prompt, ÄßÜ instead of [~]. To fix this locally, press <COMMAND>+R then <ENTER>. Confirm the reset command causes the problem by entering it at the prompt. Reset the terminal again.

To verify your terminal emulation, enter the Telnet prompt while logged in by pressing ^] and type environ list. You should see the current emulation listed. Enter the Telnet prompt again and enter toggle termdata. This debug mode will display sent and received data in hex.

Now when you enter reset you will see the control sequence string sent by the NAS utelnetd server.

You can find references to the ANSI Escape Sequences here:

http://www.termsys.demon.co.uk/vtansi.htm
http://en.wikipedia.org/wiki/ANSI_escape_code

[stevebow]

Code: Select all

<ESC>c
<ESC>(K
<ESC>[J
<ESC>[0m
<ESC>[?25h

I just checked what the reset command sends to PuTTY on the PC and (not surprisingly) the exact same sequence is sent.

It seems PuTTY and the standard MS telnet client both ignore the <ESC>(K sequence, perhaps explaining why it has not been picked up yet. I don't know why the OS X telnet client does what it does, in any case the typo in the sequence ought to be fixed.

[AndyChuo]

Thanks for reporting stevie, we will fix this issue.

Thanks

[stevebow]

Thanks, nice to know.

[AndyChuo]

It's fixed in the coming release, thanks stevebow.

[stevebow]

It's fixed in the coming release, thanks stevebow.

Cheers!

[w_m0zart]

Check which reset you are using and to which busybox that has a symbolic link. I had it linked to /opt/bin/busybox instead of /bin/busybox. Changing the symbolic link from /opt/bin/reset to /bin/busybox solved it.

For more info see the last lines here: http://forum.qnap.com/viewtopic.php?f=3 ... 15#p292916