No, I will keep using telnet over netcat. I’m not remembering and looking up those switches over and over.
If I’m automating port checks, I’m probably using neither. But if I want to check if something is listening then I can remember the telnet command and will use that.
That was my first thought. Both the bash and expect scripts seem more complicated than the equivalent Python.
expect requires me to know a fairly niche DSL, and the bash version requires me to remember a bunch of arcane info like the ability to make TCP connections by echoing into /dev.
I would push back on an MR with either of the first two. The bash+nc one I could live with, though.
Yes, certainly. But, for me, the reason I’m telnetting to ports is because I just want to check as a one off. If I check so frequently that I need an alias, I’ll use something else. So if I want a quick hack, I just need a quick hack.
Not sure why nc is that much better for me to tell if something is listening on a port.
> This works perfectly fine, assuming you're testing only one service and one port
... which is what I'm doing about 99% of the time.
I usually don't use telnet just because it's usually (annoyingly) not installed any more, so I have to stop and try to remember how to do the same thing with nc.
"Stop using telnet" sounds like it's advocating to stop using telnet because of something that's wrong with it. The article actually is about writing scripts to do more complex things on top of telnet and other utilities.
While the content in the article is useful the title is misleading.
I've realised I feel like a total fish out of water when I've gone back to Windows this week (work...) and haven't got invaluable tools like netcat/netstat to test whether things are actually doing / listening to what I think they should be. Telnet seems to be the only obvious (semi-)OOTB option there.
What do people who end up doing haxxy dev work in windows do in these kind of situations (testing if ports are listening / open in Docker containers / WSL, listing out listening ports). It seems the tooling is often "Use this tool (telnet) in a hacky way", or "Download this horrible GUI".
> What do people who end up doing haxxy dev work in windows do in these kind of situations
Windows has ping and tracert installed and working without administrative priviliges by default. Truly extraordinary feat many Linux distros are still not able to achieve.
And in my experience 99.9% network issues are debugged with the trio of ping/tracert/telnet.
I think CAP_NET_RAW is there for just about all linux distros now.
Yeah telnet just about does it, unfortunately not for UDP ports though, and still lacking a built in way to see what port is being held without grabbing procexp. It still feels like if you've got WSL sat there, thats still a much more capable place to mess about with this stuff (and this is coming from someone who spent the first half of their career building out Windows Server deployments).
Windows does have netstat, PowerShell has Test-NetConnection for testing port connectivity, and while I use puTTY I believe you can install telnet as an optional feature.
I'm not going to stop using telnet to check ports when I just need to do a one-off, ad-hoc test directly from the command line. Too much muscle memory acquired around typing "telnet $host $port". But I DO use nc instead when writing scripts that need to test ports.
I borrowed the nc approach from one of the answers on this SO thread, which has some moderately interesting stuff in it:
Well it ain't in OpenSUSE Tumbleweed, Arch, or Gentoo. Though I don't know which software is installed out of the box in Fedora, Debian, the many Debian derivatives, and all of the smaller distros out there; so you may still be right.
This is getting to be less and less true. `telnet MACHINE PORT` was my go to quick connectivity test for a couple of decades. And increasingly that's being replaced to me having to think about the right non-telnet way to do it.
I just use netcat, but that set off the security alarms at work once. SecOps messaged me and after they realized I was legitimate and not nefarious I never heard back.
This article just seems silly. As many have mentioned nobody is using telnet to check multiple ports (outside of a handful). If you need to "automate" checking ports, nmap has always been the tool. The choice between telnet and netcat has just been personally preference or availability.
I also hate the title of this article, really sick of seeing "Stop using X".
Vs
> telnet raspberrypi 22
No, I will keep using telnet over netcat. I’m not remembering and looking up those switches over and over.
If I’m automating port checks, I’m probably using neither. But if I want to check if something is listening then I can remember the telnet command and will use that.