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.

Daniel Griscom
  • 201
  • 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 – Giacomo Catenazzi Jan 18 '24 at 08:44
  • @GiacomoCatenazzi I'll check this with Wireshark and see exactly what's transpiring between telnet and the USR-TCP232-T2; will report back. – Daniel Griscom Jan 19 '24 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 '24 at 13:24
  • I figured it out: see the edit to my question. I'll likely post a new answer based on https://unix.stackexchange.com/a/311680/88234 , which I've used many times in the past although not over the network. – Daniel Griscom Jan 19 '24 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). – Giacomo Catenazzi Jan 22 '24 at 08:51
  • @GiacomoCatenazzi The converter isn't the problem, except that it can't be configured to negotiate Telnet protocol. The problem is Telnet; it insists on sending negotiation characters when put into binary mode. – Daniel Griscom Jan 23 '24 at 10:25

1 Answers1

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^
Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • 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?) – Giacomo Catenazzi Jan 18 '24 at 08: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). – Daniel Griscom Jan 19 '24 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 – Chris Davies Jan 19 '24 at 12:53