I use telnet to connect to a terminal server, which proxies the traffic to a RS-232 port.

Unfortunately when using some of the devices it is not possible to send the CTRL+C character (0x03). Instead of transmitting the character, it seems like the local client has catches the keystroke, and I'm left in "some-other-mode". What I wanted was just to send a character.

To debug this I have been playing around with:

^] toggle termdata


^] toggle options

Here is what happens when I press CTRL+C on a terminal server which does not work:

telnet 2012
Connected to termserv-val3 (
Escape character is '^]'.
telnet> toggle options
Will show option processing.
telnet> toggle termdata
Will print hexadecimal representation of terminal traffic.

Here is what happens on terminal servers which do work:

telnet termserv-val2 2012
Connected to termserv-val2 (
Escape character is '^]'.

telnet> toggle options
Will show option processing.

telnet> toggle termdata
Will print hexadecimal representation of terminal traffic.
< 0x0   03

I have tried toggle localchars but it did not make any difference.

I have also tried mode character which allowed me to send the CTRL+C character, but here I did not get any output back from the device.

How can I configure my telnet client to solve this?


Have you tried turning off localchars in your telnet client?

bash$ telnet
telnet> toggle localchars
Won't recognize certain control characters.
telnet> open myhost

You may also be able to put this command in the ~/.telnetrc file, depending on your version of telnet.

  • I have tried that (read the last part of the question) – Allan Jul 18 '12 at 12:52

You might try the 8-bit clean mode... it stops telnet from interpreting much of the data

telnet -8 host port

(This is a shot in the dark)

For the most part, you're on the right track, trying to get telnet to stop pre-interpreting keystrokes... such as the CTRL-C and CTRL-Z and others. 8bit mode should help.

  • 1
    I have tried this, it did not work. I did how ever find another solution: the terminal server can be configured to act as "TCP server mode" (default settings, which I have problems with), but if this is changed to "Real COM mode" things are working. I have no idea of what the actually differences are... – Allan Jul 6 '12 at 6:26
  • congratulations on finding a solution. Always good to get a problem fixed. – lornix Jul 6 '12 at 6:28
  • Year... I'm not too happy with this solution, I would rather have it solved by making changes in my telnet client configuration – Allan Jul 12 '12 at 10:46
  • 1
    @Allan please submit your comment as an answer at mark it as the correct answer for fixing the issue, thanks. – Not Available Jul 12 '12 at 11:55

This might help, although it uses 3 other tools instead of telnet:

echo 03 | xxd -r -p | nc host port


^C is a break character. You can send it with a telnet escape (default is ^]) and then send brk.

  • 2
    Telnet's BRK sequence has implementation-specific significance on the receiving end and is not the same as sending the ETX (^C) character. On Unixy systems, it usually means to do the TCSBRK ioctl on whatever TTY telnetd is using. On serial devices, that often translates to holding the transmit line low for a quarter to half a second. – Blrfl Jul 14 '12 at 13:33

I used 'toggle options' and 'toggle termdata' to verify the situation at my site matches that of the original poster. I was able to send the ^C (control-C) character specifically with the telnet command 'send ip' as described in the documentation. In my case I put all 3 commands in my ~/.telnetrc

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.