telnet send IAC ABORT in some Tranditional Chinese UTF-8 character

[黃于真]

When I telnet to some MUD server and chat,
> say 本
telnet client send 'IAC ABORT's, and MUD server get the wrong input.

1. what telnet send :
telnet> toggle
Need an argument to 'toggle' command. 'toggle ?' for help.
telnet> toggle options
Will show option processing.
say 本
SENT IAC ABORT
SENT DO TIMING MARK

2. What MUD server received (from strace)
readv(8, [{"say \346\377\356\377\375\6", 10}], 1) = 10
epoll_ctl(3, EPOLL_CTL_MOD, 8, {EPOLLIN|EPOLLOUT, {u32=8, u64=8}}) = 0
writev(8, [{"\377\373\6", 3}], 1) = 3

'本' is 0xe6,0xac,0x9c
but the MUD server got :
0xe6, 0xff, 0xee, 0xff, 0xfd, 0x06

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Camilio (camille-gonnet-free)]

The same problem happens with other UTF8 characters, like Ü or Ï.
For instance, Ü is coded as 0xC3 0x9C. As telnet is basically 7-bits, 0x9C is seen as 0x1C, which is Ctrl-O. And Ctrl-O is used to flushoutput.
So, telnet sends the 0xC3, then send the flushoutput IAC sequence.
本 is coded as 0xe6 0x9c 0xac, so there is also the Ctrl-O found inside.

To make it work, you need to deactivate some control codes, like those at least:
```
set flushoutput off
set quit off
```

Then netkit-telnet package should be corrected to detect UTF8 sequences and to ignore extra UTF8 bytes for control sequences.

[Brian Murray (brian-murray)]

The upstream Debian bug report makes reference to the man page which includes the following:

-8 Request 8-bit operation. This causes an attempt to negotiate the
        TELNET BINARY option for both input and output. By default telnet
        is not 8-bit clean.

Have you tried using that option?