Using telnet command without protocol negotiation

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](https://www.pusr.com/products/serial-to-ethernet-converter-modules-usr-tcp232-t2.html) * 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.