Telnet has been around ever since I was born. No..really..it was developed in 1968 and the very first protocol used on the ARPAnet. That’s right kids, when grandpa wanted to send an email, he used telnet.
I don’t think I have used Telnet for its intended use since the late nineties, but for years and years, enabling the stock Microsoft telnet client has been part of my routine setup script for any windows box I work with.
dism /Online /Get-FeatureInfo /FeatureName:telnet-client
For me and many of my colleagues, this is often the simplest, albeit crude, tool to help determine if a remote machine is listening on a specific port. Its certainly not the only tool, but one is nearly guaranteed that this can be found on any windows OS.
On linux, Netcat is a similarly ubiquitous tool that is typically installed with most distributions:
nc -z -w1 boxstarter.com 80;echo $?
This will return 0, if the specified host is listening on port 80.
Why is this important?
Perhaps you are a web developer and your web site goes down. One key troubleshooting step is to determine if the web server is even up and listening on port 80. Or maybe SSL traffic is broken and you are wondering if the server is listening to port 443. The answer to these questions may very well tell you which of many possible paths is the best to pursue in finding the root of your problem.
So you whip out your command line console and simply run:
telnet myhost.com 80
If the machine is in fact listening on port 80, I will likely get a blank screen. Otherwise, the command will hang and eventually timeout. This always felt clunky, but it worked. Oh sure, since powershell became available, I could write a script that worked with the .net library to construct a raw socket to reach an endpoint and thereby get the same information. But that’s just more code to write.
A better way
Since powershell version 4 which ships with Windows 8.1 and server 2012R2, there is a new cmdlet that provides a much more elegant means of getting this information.
C:\dev\WinRM [v1.3]> Test-NetConnection -ComputerName boxstarter.org -Port 80 WARNING: Ping to boxstarter.org failed -- Status: TimedOut ComputerName : boxstarter.org RemoteAddress : 168.62.20.37 RemotePort : 80 InterfaceAlias : vEthernet (Virtual External Switch) SourceAddress : 192.168.1.7 PingSucceeded : False PingReplyDetails (RTT) : 0 ms TcpTestSucceeded : True C:\dev\WinRM [v1.3]>
So now I have the same information plus some other bits of useful data given to me in a much more easily consumable format. Not only can I see that a site is responding to TCP port 80 requests, I see the IP address that the host name resolves to and I notice that the server is configured not to respond to ping requests.
Some may complain that Test-NetConnection requires far too many key strokes. Well there is a built in alias that points to this cmdlet allowing you to shorten the above command to:
TNC boxstarter.org -port 80
And if you don’t like having to include the -Port parameter name, the -CommonTCPPort is the next parameter in the default parameter order which takes the possible values of "HTTP,RDP,SMB,WINRM". So this means you get the same result as the command above using:
TNC boxstarter.org HTTP
So lose the telnet, and remember TNC – and welcome to the twenty first century!