Tech Tip: How to tell whether a TCP port is blocked or not listening

Document created by ScottOrzechowski Employee on May 5, 2016Last modified by SamCreek on Dec 17, 2016
Version 2Show Document
  • View in full screen mode

Tech Tip: How to tell whether a TCP port is blocked or not listening



Technical Tip Description:   



Spectrum relies on TCP connectivity between SpectroSERVERs and OneClick servers, between OneClick servers and clients, and other clients and servers.  Failure to establish a socket on a defined port can manifest itself in various ways. Note that the terms "client" and "server" are relative to whether the application is requesting data or sending it; "server" does not necessarily mean "SpectroSERVER."


If your OneClick server can't connect to your Main Location server, then when you plug the URL to the OneClick server into your browser, your browser will give you an authorization failure.  If you attempt to connect to a OneClick server, and the tomcat port is blocked, your browser will say that the connection is refused.  There are other more subtle manifestations.  If port 14001 on the OneClick server is blocked for example, you will be able to open a OneClick client, but your alarms will not update.  These are just a few examples.

Ports can be blocked by firewalls, or by IPTables on a Linux machine or Windows firewall, or host intrusion prevention software, for example.  It could also be that the packets are getting dropped on the network, or the server is simply not listening on the port on which it is expected to be listening.  Log files and other troubleshooting steps could lead you to determine that a socket cannot be established.





If you suspect that a socket cannot be established, go to the machines on each side of the expected connection and see what happens when you attempt to establish the connection.



A packet capture will definitively tell you whether the SYN packets are getting to the server, and whether the ACK packets are getting to the client.  If you can't get a packet capture, try netcap, or nc, on a Linux machine.  If you have a Linux client machine, you can use nc to determine whether the server is listening on the desired port.  Consider a SpectroSERVER that is trying to connect to a OneClick server with the address  In this context, the SpectroSERVER is the client, and the OneClick server is the server.  From the SpectroSERVER, run:


nc -z -v 14001


The z says to test the port.  The v is for verbose output.  Without the v you will get no output.  Here is what you could see:


connect to port 14001 (tcp) failed: Connection refused



Connection to 14001 port [tcp/*] succeeded!




To get even more data, you can run nc on the server side at the same time.  First you will need to stop the process that is ostensibly listening on the respective port (netstat -an would tell you).  Then use nc to listen on the port:


nc -v -l 14001


and go to the SpectroSERVER and run:


nc -z -v 14001


A successful connection would result in this output on the SpectroSERVER:

Connection to 14001 port [tcp/*] succeeded!


and this on the OneClick server:

port 14001 [tcp/*] accepted


If you don't see any output on the OneClick machine, you can infer that the packet didn't get there. It was blocked somewhere along the way.



Netcat can be added to a Solaris machine as a package.



There are no equivalent out of the box Windows commands, but there are freeware utilities available, such as "Why Can't I Connect" (not endorsed by CA) that serve the same purpose.