Comment by jcrawfordor | Hacker News Reader

Comment by jcrawfordor | Hacker News Reader

I think a lot of this type of affection for telnet is misplaced. The fact that telnet functions acceptably as an arbitrary TCP client is an unintentional side effect of the design, not its purpose. netcat is not only a more feature complete tool for simple network connections and diagnosis, it gives clearer and more helpful output on the state of the connection when used with the verbose flag.

The telnet client and protocol offer various gotchas that can appear as mysterious problems when you use them for troubleshooting instead of netcat. For example, telnet is not 8-bit clean because of the fact that it was designed specifically as a protocol to carry 7-bit ASCII. RFC 856 seeks to address this and netkit telnet can be told to behave in RFC 856 mode using the -8 option, but there can be variations between clients in this regard, and virtually no one uses the -8 flag anyway. netkit (Linux) telnet without the -8 option will behave oddly whenever non-ASCII characters are encountered, as they will be interpreted as control codes in the telnet protocol.

It is a bit ironic, in this regard, that people using telnet as a TCP client almost always seem to be using it to troubleshoot SMTP - another protocol which is, for historic reasons, not 8-bit clean without extra work!

And that kind of gets at the biggest problem: telnet is not an arbitrary TCP connection utility, it specifically implements the telnet protocol. The telnet protocol is very simple, but it is there, and common telnet clients will send unsolicited (by the user) bytes in various circumstances in order to perform the telnet protocol. This can break the state of other protocols when you use telnet as a TCP client.

If you want a tool for network diagnosis or arbitrary connections, it is netcat. Telnet for this purpose is just a workaround that is becoming quite obsolete as fewer distributions include telnet by default (removing its primary advantage over netcat, that it is "already there"). Even bash's odd built-in TCP functionality is a better choice than telnet in a lot of these situations, as it's simpler and won't try to conform to the telnet protocol.

Part of it to be fair comes to telnet being ubiquitous. I've used any number of aix / hp-ux / solaris / Linux / windows / whatever systems over the decades, with limited or high privileges, and telnet was the one command that worked on all and could within 3 seconds and no fancy docs or knowledge and additional tools tell me the basics of what I needed to know. Are there better tools? Ab so freaking lutely. But telnet is there :-)

My 100 Croatian lipa

Twenty years ago, sure. Yet I every time I have the urge to use telnet on a modern system, I have to install it. You may as well install netcat if it is available (and if it is suitable to the task).

I had to point out that one may as well install better tooling more appropriate to the domain if one would have to install telnet, some years back. (-:

* https://unix.stackexchange.com/a/499755/5132

And if telnet is not there, then curl very often is, and one can usually then just do curl -v telnet://target:port

Or better still: curl -v tcp://target:port, and avoid the issues with telnet protocol specifics entirely, with fewer keystrokes.

Never tried this, great tip!

Sadly, on many systems tcp: is disabled by default - certainly that way in debian, whereas telnet isn't shrug

Bash is more common than telnet:

echo test > /dev/tcp/<ip>/<port>

This is correct, telnet will send IAC codes (0x255) followed by two bytes. WILL, WONT, DO, DONT. If telnet encounters a IAC code, it will read the next two bytes or subcommand bytes hiding that from your output. Telnet should not be used for TCP debugging.

0xff right? decimal 255?

Anyway though I have actually had to write a from scratch parser/interface to a custom and mostly undocumented old telnet system including multiple subprotocol negotiations and it really is pretty shitty. Even using it for more or less its intended purpose sucks.

Yes 0xFF, my brain short circuited. It’s a hairy protocol unless you scan byte by byte into a buffer, branching when you receive IAC codes. Because they can come mid-stream. Anytime. Anywhere in the buffer of packet data.

Any good resource recommendation for a concise overview how to use netcat for connectivity debugging?

I use "telnet -8 -E" for our VAX (which runs on the Charon emulator).

We have Multinet ssh, but not enough ram and sundry resources to support 300+ concurrent sessions.

I have a container with TinySSH, with /etc/passwd accounts for each of our VAXes. These accounts are set to "exec telnet -8 -E (vaxhost)."

We used to use the Reflections terminal emulator with an stunnel binary packaged with it. Reflections is now over $500 per seat in licensing, and Rocket is under $100.

Rocket terminal refuses to allow a self-signed cert, and instead of renewing certs every two years, we push a private key to all our VAX users with Rocket, that launch the telnet.

Without the -8 option, the line-drawing characters don't render properly.

There was quite a bit of trial and error in getting this right.

All this is true, but back in the early 90s... we just didn't have netcat, and telnet was on every single machine, and so that's what we used as a MUD client, for remote shell access, for system diagnosis to see if a port was open, for ad-hoc SMTP sessions, etc. My brain is still unfortunately wired to reach for it and I have never memorized the netcat flags in the same way.

It wasn't just for troubleshooting SMTP, it was also great for debugging HTTP when you were serving malformed headers causing your browser to explode. Is that technically the wrong solution? Okay, dad, but it was also my gaming platform at the time.

Reply on news.ycombinator.com