17

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

and

^] toggle options

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

telnet 10.10.129.101 2012
Trying 10.10.129.101...
Connected to termserv-val3 (10.10.129.101).
Escape character is '^]'.
^]
telnet> toggle options
Will show option processing.
^]
telnet> toggle termdata
Will print hexadecimal representation of terminal traffic.
SENT IAC IP
SENT DO TIMING MARK

Here is what happens on terminal servers which do work:

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

telnet> toggle options
Will show option processing.

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

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?

1
  • 2
    What terminal server is this? Jul 12, 2012 at 23:52

9 Answers 9

6
+50

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.

3
  • I have tried that (read the last part of the question)
    – Allan
    Jul 18, 2012 at 12:52
  • I have the same problem. I tried using toggle localchars, but nothing changes. Using wireshark I can see that instead of 0x03 telnet sends ff f4 ff fd 06 Jun 28, 2022 at 7:57
  • I realize it has been ten years since the original question, but this recently popped up thanks to @mastupristi's recent comment. You could try changing your terminal's intr character (on the local system) prior to running telnet. Something like stty intr undef might do the trick. There might be some other stty settings that could help, also... check man stty to see what your system has available. On my mac, I have ignbrk which tells the terminal to ignore the break signal.
    – jlp
    Aug 27, 2022 at 7:18
3

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

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

3

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.

4
  • 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, 2012 at 6:26
  • congratulations on finding a solution. Always good to get a problem fixed.
    – lornix
    Jul 6, 2012 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, 2012 at 10:46
  • 1
    @Allan please submit your comment as an answer at mark it as the correct answer for fixing the issue, thanks. Jul 12, 2012 at 11:55
1

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

2
  • 3
    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, 2012 at 13:33
  • Not sure if it changes anything, but there's also quit command in telnet available. Oct 14, 2019 at 11:16
1

I was struggling with this and not finding an answer by Googling. This is a very old thread, but I will leave this in case someone else comes here looking for a solution like I did.

  1. Go into telnet command mode with Ctrl+]
  2. Enter the command: mode character. This puts telnet into character mode, which for whatever reason now works as you would expect, Crtl+C and all.
0

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

0

I ran into a similar issue regarding not being able to send ^C (Control-C) to through the telnet session. Additionally, I was getting serial over the telnet session and there was a echo each time I interacted with the terminal. That is when I entered "a" in a linux bash shell I'd get "a" back twice and a "a: command not found" or I'd get two prompts back upon that is: $ $

I resolved this issue by ensuring the telnet session I was using was configured to use RFC2217 protocol. This corrected the anomalies of the serial terminal and the echos and "control" characters were properly interpreted. See https://www.rfc-editor.org/rfc/rfc2217

0

Use

nc host port

If what you want is just connect to a server-port and interrupt with Ctrl+C when needed. You can install nc with the netcat package.

P.S. the idea is taken from @bambam's answer but I don't know what's the meaning of xxd command that was used, and it works just fine without it for my use case.

0

In the non-working case, the output

SENT IAC IP
SENT DO TIMING MARK

indicates that either the TELNET LINEMODE option has been "successfully" negotiated with the remote end, or the localchars option is TRUE and the connection is using the "old line by line" mode.

In these situations, the Control-C keystroke is being sent as the corresponding Telnet protocol sequence (IAC IP = Interpret as Command: Interrupt Process).

But in the working case, the Control-C is simply sent out as ASCII character 0x03. That suggests Telnet is working in character mode, with no local interpretation of special characters.

So, it looks like you'd need to disable the LINEMODE option (mode character), and/or set LOCALCHARS to FALSE (unset localchars). Since you've tried both in isolation and it did not work, it looks like the terminal server specifically needs both of them together.

To do that, you could put this into your ~/.telnetrc:

10.10.129.101
  mode character
  unset localchars

termserv-val3
  mode character
  unset localchars

(specified both by IP address and hostname, just in case you don't always refer to the terminal server in the same way)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .