0

I'm using telnet to connect to a serial port via a TCP/IP server. I need a raw, unfiltered, unbuffered connection, and can get most of the way there, but no matter what I do telnet sends protocol negotiation commands when it connects.

This is strange, because "man telnet" page says:

When connecting to ports other than the telnet port, telnet does not attempt telnet
protocol negotiations. This makes it possible to connect to services that do not
support the telnet protocol without making a mess.

But, although I'm connecting to a non-standard port, telnet negotiates:

linuxdev:~ griscom$ telnet 172.16.250.49 2023
Trying 172.16.250.49...
Negotiating binary mode with remote host.
Connected to 172.16.250.49.
                           Escape character is '^]'.

And, as the man page warns, this makes a mess.

Is there a way to use telnet as a completely transparent TCP/IP client? Or, is there some other tool I could use?

Details:

  • Running telnet on an Ubuntu 22.04 system
  • Server is a USR-TCP232-T2 ethernet to serial converter
  • Serial port is connected to a Linux system's console, so I need unbuffered transparency so I can, e.g. run vim or type control characters

Edit: I figured out the problem. telnet by default runs in "line" mode, collecting characters and sending them the next time a CR is typed. I need it to run in "character" mode, where it sends data as-is.

Problem: I can't set "character" mode without telnet negotiating that change with the other end of the line. Proof: if I connect to the serial adapter with an unconfigured telnet, I'll get no negotiation characters sent to the adaptor. But, if I use ^] to drop into command mode, and then type mode character, telnet will immediately negotiate with the other end, making a mess. (The same thing happens if I use a .telnetrc file to configure the connection to character mode.)

So, there's no way for telnet to connect to a port in "character" model without sending spurious command bytes to that port. I'll need a different solution.

6
  • 1
    To me, it seems that the device will start negotiation, and probably it set to the right values. You should try to find if the negotiation is ok, and ev. configure the converter Jan 18 at 8:44
  • @GiacomoCatenazzi I'll check this with Wireshark and see exactly what's transpiring between telnet and the USR-TCP232-T2; will report back. Jan 19 at 11:51
  • You can get debug output from the telnet client by creating a file ~/.telnetrc with remote hostname on 1st line, and ` set options` indented by 1 space on 2nd line. eg printf '172.16.250.49\n set options\n' >~/.telnetrc
    – meuh
    Jan 19 at 13:24
  • I figured it out: see the edit to my question. I'll likely post a new answer based on unix.stackexchange.com/a/311680/88234 , which I've used many times in the past although not over the network. Jan 19 at 20:06
  • Did you check what you can configure in your converter? I think the first step is to optimize configuration then you may find a way not to negotiate. And if it negotiate, it means that the client know what is it doing. Note: for sure you can configure: serial ports requires a lot of configuration (baud, start/stop bit, parity, etc.). Often it is in a different TCP port (e.g. one less the normal communication port). Jan 22 at 8:51

1 Answer 1

1

You can use netcat (nc) for a transparent connection

   nc {host} {port}

Although the telnet client is correctly not attempting negotiation, it will always respond to a negotiation request by the server. I believe that may be what's happening in this instance. You can avoid any and all negotiation by using nc.

Note that you may find nc appears to be in line mode. It isn't, it's just that the terminal driver hasn't been asked to go into raw mode:

stty raw; nc {host} {port}

Once you do this you will not be able to use the terminal session to quit nc; you will need to send it a signal from elsewhere:

ps | grep -w nc    # 60883 pty0     00:00:00 nc
kill 60883         # ^this^
3
  • I do not think it is a fault of telnet package. From what I get of the message, it is the device which starts negotiation (else: why getting binary mode?) Jan 18 at 8:43
  • Unfortunately, nc still cooks the output, doing I/O line by line with local echo, which plays hell with (e.g.) running vim. It also interprets control characters locally (e.g. ^C, ^D). Jan 19 at 11:47
  • @DanielGriscom it's not nc that's processing the characters in line mode. See: stty raw; nc {host} {port}, but don't expect to be able to exit from it - you'll need to send it a signal from elsewhere. I've updated my answer Jan 19 at 12:53

You must log in to answer this question.

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