Test if a port on a remote system is reachable (without telnet)
In the old days, we used telnet
to see if a port on a remote host was open: telnet hostname port
would attempt to connect to any port on any host and give you access to the raw TCP stream.
These days, the systems I work on do not have telnet installed (for security reasons), and all outbound connections to all hosts are blocked by default. Over time, it's easy to lose track of which ports are open to which hosts.
Is there another way to test if a port on a remote system is open – using a Linux system with a limited number of packages installed, and telnet
is not available?
linux networking port
add a comment |
In the old days, we used telnet
to see if a port on a remote host was open: telnet hostname port
would attempt to connect to any port on any host and give you access to the raw TCP stream.
These days, the systems I work on do not have telnet installed (for security reasons), and all outbound connections to all hosts are blocked by default. Over time, it's easy to lose track of which ports are open to which hosts.
Is there another way to test if a port on a remote system is open – using a Linux system with a limited number of packages installed, and telnet
is not available?
linux networking port
Related: check status of one port on remote host at SO
– kenorb
Dec 30 '15 at 14:50
add a comment |
In the old days, we used telnet
to see if a port on a remote host was open: telnet hostname port
would attempt to connect to any port on any host and give you access to the raw TCP stream.
These days, the systems I work on do not have telnet installed (for security reasons), and all outbound connections to all hosts are blocked by default. Over time, it's easy to lose track of which ports are open to which hosts.
Is there another way to test if a port on a remote system is open – using a Linux system with a limited number of packages installed, and telnet
is not available?
linux networking port
In the old days, we used telnet
to see if a port on a remote host was open: telnet hostname port
would attempt to connect to any port on any host and give you access to the raw TCP stream.
These days, the systems I work on do not have telnet installed (for security reasons), and all outbound connections to all hosts are blocked by default. Over time, it's easy to lose track of which ports are open to which hosts.
Is there another way to test if a port on a remote system is open – using a Linux system with a limited number of packages installed, and telnet
is not available?
linux networking port
linux networking port
edited Jul 19 '13 at 21:17
Steve HHH
asked Jul 19 '13 at 16:54
Steve HHHSteve HHH
2,99062133
2,99062133
Related: check status of one port on remote host at SO
– kenorb
Dec 30 '15 at 14:50
add a comment |
Related: check status of one port on remote host at SO
– kenorb
Dec 30 '15 at 14:50
Related: check status of one port on remote host at SO
– kenorb
Dec 30 '15 at 14:50
Related: check status of one port on remote host at SO
– kenorb
Dec 30 '15 at 14:50
add a comment |
12 Answers
12
active
oldest
votes
Bash has been able to access TCP and UDP ports for a while. From the man page:
/dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a TCP connection to the corresponding socket.
/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a UDP connection to the corresponding socket.
So you could use something like this:
xenon-lornix:~> cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_6.2p2 Debian-6
^C pressed here
Taa Daa!
This also seems to work in MinGW. For instance, a remote VNC server on 192.168.2.100 responds with "RFB 003.008" by using "cat < /dev/tcp/192.168.2.100/5900".
– Peter Mortensen
Jul 21 '15 at 11:26
1
@lornix, ok, but in this case I have to get the same result with use nc without -z option, but it still does not work: # nc -v -w5 127.0.0.1 18080 Connection to 127.0.0.1 18080 port [tcp/*] succeeded! # cat < /dev/tcp/127.0.0.1/18080 Just hangs without any result. Just want to understand when I can use "/dev/tcp/host/port" option
– Alexandr
Jun 14 '16 at 7:09
5
@Alexandr... actually, "hangs without any result" is pretty much expected behavior. cat is waiting for input. nc has extra smarts to enable it to sense no-data pending and stops trying. cat isn't quite as smart. Trycat < /dev/tcp/localhost/22
, you should get your sshd header. Evidently, your process on port 18080 waits for something to come in, before sending anything. Port 22 (ssh) greets you with it's version and whatnot. Try it out!
– lornix
Jun 14 '16 at 8:44
1
@lornix, thank you very much for explanation! Now the restriction is clear. I think using nc should be a preferred way to check ports.
– Alexandr
Jun 14 '16 at 14:29
2
This was incredibly helpful when working with a docker container that had nothing installed. Was able to quickly verify that the container had access to non-containerized DB via DNS. Example: cat < /dev/tcp/hostname/5432
– Michael Hobbs
Oct 24 '18 at 14:09
|
show 11 more comments
Nice and verbose! From the man pages.
Single port:
nc -zv 127.0.0.1 80
Multiple ports:
nc -zv 127.0.0.1 22 80 8080
Range of ports:
nc -zv 127.0.0.1 20-30
4
Seems to be far the bestest answer, thanks. ;-)
– lpapp
Nov 26 '14 at 15:42
5
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 12:36
4
Use -u option for UDP ports.
– Efren
Sep 21 '16 at 0:10
7
On version 6.4 of ncat -z is not recognized. I was able to do without z
– smishra
Apr 6 '17 at 17:18
4
You can check multiple ranges with:nc -zv 127.0.0.1 22,80,8080,20-30,443-446
(nc Version: 1.107-4).
– bobbel
Jul 6 '17 at 16:55
|
show 3 more comments
Netcat is a useful tool:
nc 127.0.0.1 123 &> /dev/null; echo $?
Will output 0
if port 123 is open, and 1
if it's closed.
This is a far more elegant and scriptable answer than my own. It is unfortunate for me that the security-conscious sysadmins who withheldtelnet
also withheldnc
(though – strangely – notcurl
orwget
).
– Steve HHH
Jul 19 '13 at 19:51
Yes that is completely arbitrary and silly.
– thnee
Jul 19 '13 at 20:10
3
Let theFOR
statements begin!
– Chad Harrison
Jul 19 '13 at 21:37
1
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after about 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open, returning 0. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 13:06
I think-G 2
would be more appropriate for TCP timeout
– A B
Aug 24 '15 at 21:45
|
show 5 more comments
The simplest method, without making use of another tool, such as socat
, is as described in @lornix's answer above. This is just to add an actual example of how one would make use of the psuedo-device /dev/tcp/...
within Bash if you wanted to, say, test if another server had a given port accessible via the command line.
Examples
Say I have a host on my network named skinner
.
$ (echo > /dev/tcp/skinner/22) >/dev/null 2>&1
&& echo "It's up" || echo "It's down"
It's up
$ (echo > /dev/tcp/skinner/222) >/dev/null 2>&1 &&
echo "It's up" || echo "It's down"
It's down
The reason you want to wrap the echo > /dev/...
in parentheses like this, (echo > /dev/...)
is because if you don't, then with tests of connections that are down, you'll get these types of messages showing up.
$ (echo > /dev/tcp/skinner/223) && echo hi
bash: connect: Connection refused
bash: /dev/tcp/skinner/223: Connection refused
These can't simply be redirected to /dev/null
since they're coming from the attempt to write out data to the device /dev/tcp
. So we capture all that output within a sub-command, i.e. (...cmds...)
and redirect the output of the sub-command.
This is excellent. Wish it would get voted up to the top. I only read this far down the page because I accidentally scrolled before closing it.
– Still.Tony
Feb 12 '15 at 13:44
@Okuma.Tony - yes that's always an issue with Q's that have many answers 8-). Thanks for the feedback though, it's appreciated.
– slm
Feb 12 '15 at 14:26
add a comment |
I found that curl
may get the job done in a similar way to telnet
, and curl
will even tell you which protocol the listener expects.
Construct an HTTP URI from the hostname and port as the first argument to curl
. If curl
can connect, it will report a protocol mismatch and exit (if the listener isn't a web service). If curl
cannot connect, it will time out.
For example, port 5672 on host 10.0.0.99 is either closed or blocked by a firewall:
$ curl http://10.0.0.99:5672
curl: (7) couldn't connect to host
However, from a different system, port 5672 on host 10.0.0.99 can be reached, and appears to be running an AMQP listener.
$ curl http://10.0.0.99:5672
curl: (56) Failure when receiving data from the peer
AMQP
It's important to distinguish between the different messages: the first failure was because curl
could not connect to the port. The second failure is a success test, though curl
expected an HTTP listener instead of an AMQP listener.
5
If curl isn't available, wget might be.wget -qS -O- http://ip.add.re.ss:port
should effectively do the same thing.
– a CVn
Jul 19 '13 at 17:52
2
This even works with a hostname, ex.curl myhost:22
.
– 에이바
Feb 25 '14 at 16:17
This may be incorrect. I am havng a tomcat service running, but getting 404 error. # curl -k 192.168.194.4:6443 <html><head><title>Apache Tomcat/7.0.34 - Error report</title><style><!--H1 --- HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - /</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>/</u></p><p><b>description</b> <u>The requested resource is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.34</h3></body></html>
– Mohammad Shahid Siddiqui
Jun 2 '15 at 6:30
See my post with similar approach.
– kenorb
Dec 30 '15 at 14:49
add a comment |
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.193.173 6443
nc: connect to 192.168.193.173 port 6443 (tcp) failed: Connection refused
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.194.4 6443
Connection to 192.168.194.4 6443 port [tcp/sun-sr-https] succeeded!
Hope it solves your problem :)
1
Yes, this is better - timing out almost immediately for closed ports.
– Peter Mortensen
Jul 21 '15 at 12:38
1
Does this always use TCP or is there a way to get it to check UDP?
– kmoe
Jan 2 '16 at 17:09
add a comment |
Here is one-liner:
</dev/tcp/localhost/11211 && echo Port is open || echo Port is closed
using Bash syntax explained in @lornix answer.
For more info, check: Advanced Bash-Scripting Guide: Chapter 29. /dev
and /proc
.
what is the timeout for closed ports?
– Tilo
Dec 12 '18 at 17:42
add a comment |
I was struggling for a whole day because none of these answers seemed to work for me. The problem is that the most recent version of nc
no longer has the -z
flag, whereas direct access via TCP (as according to @lornix and @slm) fails when the host is not reachable. I eventually found this page, where I finally found not one but two working examples:
nc -w1 127.0.0.1 22 </dev/null
(the
-w
flag takes care of the timeout, and the</dev/null
replaces the-z
flag)
timeout 1 bash -c '(echo > /dev/tcp/127.0.0.1/22) >/dev/null 2>&1'
(the
timeout
command takes care of the timeout, and the rest is from @slm)
Then, simply use &&
and/or ||
(or even $?
) to extract the result. Hopefully, somebody will find this information useful.
add a comment |
It shouldn't be available on your box, but try with nmap
.
4
nmap
is a good tool, but not available on these systems. Rather than downloadnmap
, compile it, install it to my home directory, then copy it to all the other systems, I was hoping to find a way using existing tools available in most Linux installations.
– Steve HHH
Jul 19 '13 at 17:16
add a comment |
Here's a function that will pick one of the methods depending on what's installed on your system:
# Check_port <address> <port>
check_port() {
if [ "$(which nc)" != "" ]; then
tool=nc
elif [ "$(which curl)" != "" ]; then
tool=curl
elif [ "$(which telnet)" != "" ]; then
tool=telnet
elif [ -e /dev/tcp ]; then
if [ "$(which gtimeout)" != "" ]; then
tool=gtimeout
elif [ "$(which timeout)" != "" ]; then
tool=timeout
else
tool=devtcp
fi
fi
echo "Using $tool to test access to $1:$2"
case $tool in
nc) nc -v -G 5 -z -w2 $1 $2 ;;
curl) curl --connect-timeout 10 http://$1:$2 ;;
telnet) telnet $1 $2 ;;
gtimeout) gtimeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
timeout) timeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
devtcp) </dev/tcp/${1}/${2} && echo Port is open || echo Port is closed ;;
*) echo "no tools available to test $1 port $2";;
esac
}
export check_port
add a comment |
Combining the answers from @kenorb and @Azukikuru you could test port open/closed/firewalled.
timeout 1 bash -c '</dev/tcp/127.0.0.1/22 && echo Port is open || echo Port is closed' || echo Connection timeout
Another approach with curl for reaching any port
curl telnet://127.0.0.1:22
add a comment |
If you've to test more than on system you may use our test tool dda-serverspec (https://github.com/DomainDrivenArchitecture/dda-serverspec-crate) for such tasks. You may define your expectation
{:netcat [{:host "mywebserver.com" :port "443"}
{:host "telnet mywebserver.com" :port "80"}
{:host "telnet mywebserver.com" :port "8443"}]}
and test these expectation either against localhost or against remote hosts (connect by ssh). For remote tests you've to define a targets:
{:existing [{:node-name "test-vm1"
:node-ip "35.157.19.218"}
{:node-name "test-vm2"
:node-ip "18.194.113.138"}]
:provisioning-user {:login "ubuntu"}}
You may run the test with java -jar dda-serverspec.jar --targets targets.edn serverspec.edn
Under the hood we're using netcat as proprosed above ...
add a comment |
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f621870%2ftest-if-a-port-on-a-remote-system-is-reachable-without-telnet%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
12 Answers
12
active
oldest
votes
12 Answers
12
active
oldest
votes
active
oldest
votes
active
oldest
votes
Bash has been able to access TCP and UDP ports for a while. From the man page:
/dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a TCP connection to the corresponding socket.
/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a UDP connection to the corresponding socket.
So you could use something like this:
xenon-lornix:~> cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_6.2p2 Debian-6
^C pressed here
Taa Daa!
This also seems to work in MinGW. For instance, a remote VNC server on 192.168.2.100 responds with "RFB 003.008" by using "cat < /dev/tcp/192.168.2.100/5900".
– Peter Mortensen
Jul 21 '15 at 11:26
1
@lornix, ok, but in this case I have to get the same result with use nc without -z option, but it still does not work: # nc -v -w5 127.0.0.1 18080 Connection to 127.0.0.1 18080 port [tcp/*] succeeded! # cat < /dev/tcp/127.0.0.1/18080 Just hangs without any result. Just want to understand when I can use "/dev/tcp/host/port" option
– Alexandr
Jun 14 '16 at 7:09
5
@Alexandr... actually, "hangs without any result" is pretty much expected behavior. cat is waiting for input. nc has extra smarts to enable it to sense no-data pending and stops trying. cat isn't quite as smart. Trycat < /dev/tcp/localhost/22
, you should get your sshd header. Evidently, your process on port 18080 waits for something to come in, before sending anything. Port 22 (ssh) greets you with it's version and whatnot. Try it out!
– lornix
Jun 14 '16 at 8:44
1
@lornix, thank you very much for explanation! Now the restriction is clear. I think using nc should be a preferred way to check ports.
– Alexandr
Jun 14 '16 at 14:29
2
This was incredibly helpful when working with a docker container that had nothing installed. Was able to quickly verify that the container had access to non-containerized DB via DNS. Example: cat < /dev/tcp/hostname/5432
– Michael Hobbs
Oct 24 '18 at 14:09
|
show 11 more comments
Bash has been able to access TCP and UDP ports for a while. From the man page:
/dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a TCP connection to the corresponding socket.
/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a UDP connection to the corresponding socket.
So you could use something like this:
xenon-lornix:~> cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_6.2p2 Debian-6
^C pressed here
Taa Daa!
This also seems to work in MinGW. For instance, a remote VNC server on 192.168.2.100 responds with "RFB 003.008" by using "cat < /dev/tcp/192.168.2.100/5900".
– Peter Mortensen
Jul 21 '15 at 11:26
1
@lornix, ok, but in this case I have to get the same result with use nc without -z option, but it still does not work: # nc -v -w5 127.0.0.1 18080 Connection to 127.0.0.1 18080 port [tcp/*] succeeded! # cat < /dev/tcp/127.0.0.1/18080 Just hangs without any result. Just want to understand when I can use "/dev/tcp/host/port" option
– Alexandr
Jun 14 '16 at 7:09
5
@Alexandr... actually, "hangs without any result" is pretty much expected behavior. cat is waiting for input. nc has extra smarts to enable it to sense no-data pending and stops trying. cat isn't quite as smart. Trycat < /dev/tcp/localhost/22
, you should get your sshd header. Evidently, your process on port 18080 waits for something to come in, before sending anything. Port 22 (ssh) greets you with it's version and whatnot. Try it out!
– lornix
Jun 14 '16 at 8:44
1
@lornix, thank you very much for explanation! Now the restriction is clear. I think using nc should be a preferred way to check ports.
– Alexandr
Jun 14 '16 at 14:29
2
This was incredibly helpful when working with a docker container that had nothing installed. Was able to quickly verify that the container had access to non-containerized DB via DNS. Example: cat < /dev/tcp/hostname/5432
– Michael Hobbs
Oct 24 '18 at 14:09
|
show 11 more comments
Bash has been able to access TCP and UDP ports for a while. From the man page:
/dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a TCP connection to the corresponding socket.
/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a UDP connection to the corresponding socket.
So you could use something like this:
xenon-lornix:~> cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_6.2p2 Debian-6
^C pressed here
Taa Daa!
Bash has been able to access TCP and UDP ports for a while. From the man page:
/dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a TCP connection to the corresponding socket.
/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a UDP connection to the corresponding socket.
So you could use something like this:
xenon-lornix:~> cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_6.2p2 Debian-6
^C pressed here
Taa Daa!
edited Jul 31 '15 at 22:04
Peter Mortensen
8,376166185
8,376166185
answered Jul 22 '13 at 10:37
lornixlornix
8,91812433
8,91812433
This also seems to work in MinGW. For instance, a remote VNC server on 192.168.2.100 responds with "RFB 003.008" by using "cat < /dev/tcp/192.168.2.100/5900".
– Peter Mortensen
Jul 21 '15 at 11:26
1
@lornix, ok, but in this case I have to get the same result with use nc without -z option, but it still does not work: # nc -v -w5 127.0.0.1 18080 Connection to 127.0.0.1 18080 port [tcp/*] succeeded! # cat < /dev/tcp/127.0.0.1/18080 Just hangs without any result. Just want to understand when I can use "/dev/tcp/host/port" option
– Alexandr
Jun 14 '16 at 7:09
5
@Alexandr... actually, "hangs without any result" is pretty much expected behavior. cat is waiting for input. nc has extra smarts to enable it to sense no-data pending and stops trying. cat isn't quite as smart. Trycat < /dev/tcp/localhost/22
, you should get your sshd header. Evidently, your process on port 18080 waits for something to come in, before sending anything. Port 22 (ssh) greets you with it's version and whatnot. Try it out!
– lornix
Jun 14 '16 at 8:44
1
@lornix, thank you very much for explanation! Now the restriction is clear. I think using nc should be a preferred way to check ports.
– Alexandr
Jun 14 '16 at 14:29
2
This was incredibly helpful when working with a docker container that had nothing installed. Was able to quickly verify that the container had access to non-containerized DB via DNS. Example: cat < /dev/tcp/hostname/5432
– Michael Hobbs
Oct 24 '18 at 14:09
|
show 11 more comments
This also seems to work in MinGW. For instance, a remote VNC server on 192.168.2.100 responds with "RFB 003.008" by using "cat < /dev/tcp/192.168.2.100/5900".
– Peter Mortensen
Jul 21 '15 at 11:26
1
@lornix, ok, but in this case I have to get the same result with use nc without -z option, but it still does not work: # nc -v -w5 127.0.0.1 18080 Connection to 127.0.0.1 18080 port [tcp/*] succeeded! # cat < /dev/tcp/127.0.0.1/18080 Just hangs without any result. Just want to understand when I can use "/dev/tcp/host/port" option
– Alexandr
Jun 14 '16 at 7:09
5
@Alexandr... actually, "hangs without any result" is pretty much expected behavior. cat is waiting for input. nc has extra smarts to enable it to sense no-data pending and stops trying. cat isn't quite as smart. Trycat < /dev/tcp/localhost/22
, you should get your sshd header. Evidently, your process on port 18080 waits for something to come in, before sending anything. Port 22 (ssh) greets you with it's version and whatnot. Try it out!
– lornix
Jun 14 '16 at 8:44
1
@lornix, thank you very much for explanation! Now the restriction is clear. I think using nc should be a preferred way to check ports.
– Alexandr
Jun 14 '16 at 14:29
2
This was incredibly helpful when working with a docker container that had nothing installed. Was able to quickly verify that the container had access to non-containerized DB via DNS. Example: cat < /dev/tcp/hostname/5432
– Michael Hobbs
Oct 24 '18 at 14:09
This also seems to work in MinGW. For instance, a remote VNC server on 192.168.2.100 responds with "RFB 003.008" by using "cat < /dev/tcp/192.168.2.100/5900".
– Peter Mortensen
Jul 21 '15 at 11:26
This also seems to work in MinGW. For instance, a remote VNC server on 192.168.2.100 responds with "RFB 003.008" by using "cat < /dev/tcp/192.168.2.100/5900".
– Peter Mortensen
Jul 21 '15 at 11:26
1
1
@lornix, ok, but in this case I have to get the same result with use nc without -z option, but it still does not work: # nc -v -w5 127.0.0.1 18080 Connection to 127.0.0.1 18080 port [tcp/*] succeeded! # cat < /dev/tcp/127.0.0.1/18080 Just hangs without any result. Just want to understand when I can use "/dev/tcp/host/port" option
– Alexandr
Jun 14 '16 at 7:09
@lornix, ok, but in this case I have to get the same result with use nc without -z option, but it still does not work: # nc -v -w5 127.0.0.1 18080 Connection to 127.0.0.1 18080 port [tcp/*] succeeded! # cat < /dev/tcp/127.0.0.1/18080 Just hangs without any result. Just want to understand when I can use "/dev/tcp/host/port" option
– Alexandr
Jun 14 '16 at 7:09
5
5
@Alexandr... actually, "hangs without any result" is pretty much expected behavior. cat is waiting for input. nc has extra smarts to enable it to sense no-data pending and stops trying. cat isn't quite as smart. Try
cat < /dev/tcp/localhost/22
, you should get your sshd header. Evidently, your process on port 18080 waits for something to come in, before sending anything. Port 22 (ssh) greets you with it's version and whatnot. Try it out!– lornix
Jun 14 '16 at 8:44
@Alexandr... actually, "hangs without any result" is pretty much expected behavior. cat is waiting for input. nc has extra smarts to enable it to sense no-data pending and stops trying. cat isn't quite as smart. Try
cat < /dev/tcp/localhost/22
, you should get your sshd header. Evidently, your process on port 18080 waits for something to come in, before sending anything. Port 22 (ssh) greets you with it's version and whatnot. Try it out!– lornix
Jun 14 '16 at 8:44
1
1
@lornix, thank you very much for explanation! Now the restriction is clear. I think using nc should be a preferred way to check ports.
– Alexandr
Jun 14 '16 at 14:29
@lornix, thank you very much for explanation! Now the restriction is clear. I think using nc should be a preferred way to check ports.
– Alexandr
Jun 14 '16 at 14:29
2
2
This was incredibly helpful when working with a docker container that had nothing installed. Was able to quickly verify that the container had access to non-containerized DB via DNS. Example: cat < /dev/tcp/hostname/5432
– Michael Hobbs
Oct 24 '18 at 14:09
This was incredibly helpful when working with a docker container that had nothing installed. Was able to quickly verify that the container had access to non-containerized DB via DNS. Example: cat < /dev/tcp/hostname/5432
– Michael Hobbs
Oct 24 '18 at 14:09
|
show 11 more comments
Nice and verbose! From the man pages.
Single port:
nc -zv 127.0.0.1 80
Multiple ports:
nc -zv 127.0.0.1 22 80 8080
Range of ports:
nc -zv 127.0.0.1 20-30
4
Seems to be far the bestest answer, thanks. ;-)
– lpapp
Nov 26 '14 at 15:42
5
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 12:36
4
Use -u option for UDP ports.
– Efren
Sep 21 '16 at 0:10
7
On version 6.4 of ncat -z is not recognized. I was able to do without z
– smishra
Apr 6 '17 at 17:18
4
You can check multiple ranges with:nc -zv 127.0.0.1 22,80,8080,20-30,443-446
(nc Version: 1.107-4).
– bobbel
Jul 6 '17 at 16:55
|
show 3 more comments
Nice and verbose! From the man pages.
Single port:
nc -zv 127.0.0.1 80
Multiple ports:
nc -zv 127.0.0.1 22 80 8080
Range of ports:
nc -zv 127.0.0.1 20-30
4
Seems to be far the bestest answer, thanks. ;-)
– lpapp
Nov 26 '14 at 15:42
5
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 12:36
4
Use -u option for UDP ports.
– Efren
Sep 21 '16 at 0:10
7
On version 6.4 of ncat -z is not recognized. I was able to do without z
– smishra
Apr 6 '17 at 17:18
4
You can check multiple ranges with:nc -zv 127.0.0.1 22,80,8080,20-30,443-446
(nc Version: 1.107-4).
– bobbel
Jul 6 '17 at 16:55
|
show 3 more comments
Nice and verbose! From the man pages.
Single port:
nc -zv 127.0.0.1 80
Multiple ports:
nc -zv 127.0.0.1 22 80 8080
Range of ports:
nc -zv 127.0.0.1 20-30
Nice and verbose! From the man pages.
Single port:
nc -zv 127.0.0.1 80
Multiple ports:
nc -zv 127.0.0.1 22 80 8080
Range of ports:
nc -zv 127.0.0.1 20-30
answered Dec 3 '13 at 21:34
Subhranath ChunderSubhranath Chunder
3,681172
3,681172
4
Seems to be far the bestest answer, thanks. ;-)
– lpapp
Nov 26 '14 at 15:42
5
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 12:36
4
Use -u option for UDP ports.
– Efren
Sep 21 '16 at 0:10
7
On version 6.4 of ncat -z is not recognized. I was able to do without z
– smishra
Apr 6 '17 at 17:18
4
You can check multiple ranges with:nc -zv 127.0.0.1 22,80,8080,20-30,443-446
(nc Version: 1.107-4).
– bobbel
Jul 6 '17 at 16:55
|
show 3 more comments
4
Seems to be far the bestest answer, thanks. ;-)
– lpapp
Nov 26 '14 at 15:42
5
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 12:36
4
Use -u option for UDP ports.
– Efren
Sep 21 '16 at 0:10
7
On version 6.4 of ncat -z is not recognized. I was able to do without z
– smishra
Apr 6 '17 at 17:18
4
You can check multiple ranges with:nc -zv 127.0.0.1 22,80,8080,20-30,443-446
(nc Version: 1.107-4).
– bobbel
Jul 6 '17 at 16:55
4
4
Seems to be far the bestest answer, thanks. ;-)
– lpapp
Nov 26 '14 at 15:42
Seems to be far the bestest answer, thanks. ;-)
– lpapp
Nov 26 '14 at 15:42
5
5
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 12:36
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 12:36
4
4
Use -u option for UDP ports.
– Efren
Sep 21 '16 at 0:10
Use -u option for UDP ports.
– Efren
Sep 21 '16 at 0:10
7
7
On version 6.4 of ncat -z is not recognized. I was able to do without z
– smishra
Apr 6 '17 at 17:18
On version 6.4 of ncat -z is not recognized. I was able to do without z
– smishra
Apr 6 '17 at 17:18
4
4
You can check multiple ranges with:
nc -zv 127.0.0.1 22,80,8080,20-30,443-446
(nc Version: 1.107-4).– bobbel
Jul 6 '17 at 16:55
You can check multiple ranges with:
nc -zv 127.0.0.1 22,80,8080,20-30,443-446
(nc Version: 1.107-4).– bobbel
Jul 6 '17 at 16:55
|
show 3 more comments
Netcat is a useful tool:
nc 127.0.0.1 123 &> /dev/null; echo $?
Will output 0
if port 123 is open, and 1
if it's closed.
This is a far more elegant and scriptable answer than my own. It is unfortunate for me that the security-conscious sysadmins who withheldtelnet
also withheldnc
(though – strangely – notcurl
orwget
).
– Steve HHH
Jul 19 '13 at 19:51
Yes that is completely arbitrary and silly.
– thnee
Jul 19 '13 at 20:10
3
Let theFOR
statements begin!
– Chad Harrison
Jul 19 '13 at 21:37
1
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after about 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open, returning 0. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 13:06
I think-G 2
would be more appropriate for TCP timeout
– A B
Aug 24 '15 at 21:45
|
show 5 more comments
Netcat is a useful tool:
nc 127.0.0.1 123 &> /dev/null; echo $?
Will output 0
if port 123 is open, and 1
if it's closed.
This is a far more elegant and scriptable answer than my own. It is unfortunate for me that the security-conscious sysadmins who withheldtelnet
also withheldnc
(though – strangely – notcurl
orwget
).
– Steve HHH
Jul 19 '13 at 19:51
Yes that is completely arbitrary and silly.
– thnee
Jul 19 '13 at 20:10
3
Let theFOR
statements begin!
– Chad Harrison
Jul 19 '13 at 21:37
1
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after about 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open, returning 0. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 13:06
I think-G 2
would be more appropriate for TCP timeout
– A B
Aug 24 '15 at 21:45
|
show 5 more comments
Netcat is a useful tool:
nc 127.0.0.1 123 &> /dev/null; echo $?
Will output 0
if port 123 is open, and 1
if it's closed.
Netcat is a useful tool:
nc 127.0.0.1 123 &> /dev/null; echo $?
Will output 0
if port 123 is open, and 1
if it's closed.
edited Oct 20 '15 at 18:28
answered Jul 19 '13 at 18:07
thneethnee
1,491108
1,491108
This is a far more elegant and scriptable answer than my own. It is unfortunate for me that the security-conscious sysadmins who withheldtelnet
also withheldnc
(though – strangely – notcurl
orwget
).
– Steve HHH
Jul 19 '13 at 19:51
Yes that is completely arbitrary and silly.
– thnee
Jul 19 '13 at 20:10
3
Let theFOR
statements begin!
– Chad Harrison
Jul 19 '13 at 21:37
1
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after about 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open, returning 0. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 13:06
I think-G 2
would be more appropriate for TCP timeout
– A B
Aug 24 '15 at 21:45
|
show 5 more comments
This is a far more elegant and scriptable answer than my own. It is unfortunate for me that the security-conscious sysadmins who withheldtelnet
also withheldnc
(though – strangely – notcurl
orwget
).
– Steve HHH
Jul 19 '13 at 19:51
Yes that is completely arbitrary and silly.
– thnee
Jul 19 '13 at 20:10
3
Let theFOR
statements begin!
– Chad Harrison
Jul 19 '13 at 21:37
1
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after about 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open, returning 0. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 13:06
I think-G 2
would be more appropriate for TCP timeout
– A B
Aug 24 '15 at 21:45
This is a far more elegant and scriptable answer than my own. It is unfortunate for me that the security-conscious sysadmins who withheld
telnet
also withheld nc
(though – strangely – not curl
or wget
).– Steve HHH
Jul 19 '13 at 19:51
This is a far more elegant and scriptable answer than my own. It is unfortunate for me that the security-conscious sysadmins who withheld
telnet
also withheld nc
(though – strangely – not curl
or wget
).– Steve HHH
Jul 19 '13 at 19:51
Yes that is completely arbitrary and silly.
– thnee
Jul 19 '13 at 20:10
Yes that is completely arbitrary and silly.
– thnee
Jul 19 '13 at 20:10
3
3
Let the
FOR
statements begin!– Chad Harrison
Jul 19 '13 at 21:37
Let the
FOR
statements begin!– Chad Harrison
Jul 19 '13 at 21:37
1
1
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after about 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open, returning 0. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 13:06
This hanged when tried on Ubuntu 14.04 (Trusty Tahr) for a remote server (same LAN) for closed ports (it timed out after about 127 seconds) - thus not very suitable in scripts. It did work though for a service that had a port open, returning 0. Using option "-w2" could be the solution.
– Peter Mortensen
Jul 21 '15 at 13:06
I think
-G 2
would be more appropriate for TCP timeout– A B
Aug 24 '15 at 21:45
I think
-G 2
would be more appropriate for TCP timeout– A B
Aug 24 '15 at 21:45
|
show 5 more comments
The simplest method, without making use of another tool, such as socat
, is as described in @lornix's answer above. This is just to add an actual example of how one would make use of the psuedo-device /dev/tcp/...
within Bash if you wanted to, say, test if another server had a given port accessible via the command line.
Examples
Say I have a host on my network named skinner
.
$ (echo > /dev/tcp/skinner/22) >/dev/null 2>&1
&& echo "It's up" || echo "It's down"
It's up
$ (echo > /dev/tcp/skinner/222) >/dev/null 2>&1 &&
echo "It's up" || echo "It's down"
It's down
The reason you want to wrap the echo > /dev/...
in parentheses like this, (echo > /dev/...)
is because if you don't, then with tests of connections that are down, you'll get these types of messages showing up.
$ (echo > /dev/tcp/skinner/223) && echo hi
bash: connect: Connection refused
bash: /dev/tcp/skinner/223: Connection refused
These can't simply be redirected to /dev/null
since they're coming from the attempt to write out data to the device /dev/tcp
. So we capture all that output within a sub-command, i.e. (...cmds...)
and redirect the output of the sub-command.
This is excellent. Wish it would get voted up to the top. I only read this far down the page because I accidentally scrolled before closing it.
– Still.Tony
Feb 12 '15 at 13:44
@Okuma.Tony - yes that's always an issue with Q's that have many answers 8-). Thanks for the feedback though, it's appreciated.
– slm
Feb 12 '15 at 14:26
add a comment |
The simplest method, without making use of another tool, such as socat
, is as described in @lornix's answer above. This is just to add an actual example of how one would make use of the psuedo-device /dev/tcp/...
within Bash if you wanted to, say, test if another server had a given port accessible via the command line.
Examples
Say I have a host on my network named skinner
.
$ (echo > /dev/tcp/skinner/22) >/dev/null 2>&1
&& echo "It's up" || echo "It's down"
It's up
$ (echo > /dev/tcp/skinner/222) >/dev/null 2>&1 &&
echo "It's up" || echo "It's down"
It's down
The reason you want to wrap the echo > /dev/...
in parentheses like this, (echo > /dev/...)
is because if you don't, then with tests of connections that are down, you'll get these types of messages showing up.
$ (echo > /dev/tcp/skinner/223) && echo hi
bash: connect: Connection refused
bash: /dev/tcp/skinner/223: Connection refused
These can't simply be redirected to /dev/null
since they're coming from the attempt to write out data to the device /dev/tcp
. So we capture all that output within a sub-command, i.e. (...cmds...)
and redirect the output of the sub-command.
This is excellent. Wish it would get voted up to the top. I only read this far down the page because I accidentally scrolled before closing it.
– Still.Tony
Feb 12 '15 at 13:44
@Okuma.Tony - yes that's always an issue with Q's that have many answers 8-). Thanks for the feedback though, it's appreciated.
– slm
Feb 12 '15 at 14:26
add a comment |
The simplest method, without making use of another tool, such as socat
, is as described in @lornix's answer above. This is just to add an actual example of how one would make use of the psuedo-device /dev/tcp/...
within Bash if you wanted to, say, test if another server had a given port accessible via the command line.
Examples
Say I have a host on my network named skinner
.
$ (echo > /dev/tcp/skinner/22) >/dev/null 2>&1
&& echo "It's up" || echo "It's down"
It's up
$ (echo > /dev/tcp/skinner/222) >/dev/null 2>&1 &&
echo "It's up" || echo "It's down"
It's down
The reason you want to wrap the echo > /dev/...
in parentheses like this, (echo > /dev/...)
is because if you don't, then with tests of connections that are down, you'll get these types of messages showing up.
$ (echo > /dev/tcp/skinner/223) && echo hi
bash: connect: Connection refused
bash: /dev/tcp/skinner/223: Connection refused
These can't simply be redirected to /dev/null
since they're coming from the attempt to write out data to the device /dev/tcp
. So we capture all that output within a sub-command, i.e. (...cmds...)
and redirect the output of the sub-command.
The simplest method, without making use of another tool, such as socat
, is as described in @lornix's answer above. This is just to add an actual example of how one would make use of the psuedo-device /dev/tcp/...
within Bash if you wanted to, say, test if another server had a given port accessible via the command line.
Examples
Say I have a host on my network named skinner
.
$ (echo > /dev/tcp/skinner/22) >/dev/null 2>&1
&& echo "It's up" || echo "It's down"
It's up
$ (echo > /dev/tcp/skinner/222) >/dev/null 2>&1 &&
echo "It's up" || echo "It's down"
It's down
The reason you want to wrap the echo > /dev/...
in parentheses like this, (echo > /dev/...)
is because if you don't, then with tests of connections that are down, you'll get these types of messages showing up.
$ (echo > /dev/tcp/skinner/223) && echo hi
bash: connect: Connection refused
bash: /dev/tcp/skinner/223: Connection refused
These can't simply be redirected to /dev/null
since they're coming from the attempt to write out data to the device /dev/tcp
. So we capture all that output within a sub-command, i.e. (...cmds...)
and redirect the output of the sub-command.
edited Jul 31 '15 at 22:09
Peter Mortensen
8,376166185
8,376166185
answered Sep 2 '14 at 17:59
slmslm
6,46563847
6,46563847
This is excellent. Wish it would get voted up to the top. I only read this far down the page because I accidentally scrolled before closing it.
– Still.Tony
Feb 12 '15 at 13:44
@Okuma.Tony - yes that's always an issue with Q's that have many answers 8-). Thanks for the feedback though, it's appreciated.
– slm
Feb 12 '15 at 14:26
add a comment |
This is excellent. Wish it would get voted up to the top. I only read this far down the page because I accidentally scrolled before closing it.
– Still.Tony
Feb 12 '15 at 13:44
@Okuma.Tony - yes that's always an issue with Q's that have many answers 8-). Thanks for the feedback though, it's appreciated.
– slm
Feb 12 '15 at 14:26
This is excellent. Wish it would get voted up to the top. I only read this far down the page because I accidentally scrolled before closing it.
– Still.Tony
Feb 12 '15 at 13:44
This is excellent. Wish it would get voted up to the top. I only read this far down the page because I accidentally scrolled before closing it.
– Still.Tony
Feb 12 '15 at 13:44
@Okuma.Tony - yes that's always an issue with Q's that have many answers 8-). Thanks for the feedback though, it's appreciated.
– slm
Feb 12 '15 at 14:26
@Okuma.Tony - yes that's always an issue with Q's that have many answers 8-). Thanks for the feedback though, it's appreciated.
– slm
Feb 12 '15 at 14:26
add a comment |
I found that curl
may get the job done in a similar way to telnet
, and curl
will even tell you which protocol the listener expects.
Construct an HTTP URI from the hostname and port as the first argument to curl
. If curl
can connect, it will report a protocol mismatch and exit (if the listener isn't a web service). If curl
cannot connect, it will time out.
For example, port 5672 on host 10.0.0.99 is either closed or blocked by a firewall:
$ curl http://10.0.0.99:5672
curl: (7) couldn't connect to host
However, from a different system, port 5672 on host 10.0.0.99 can be reached, and appears to be running an AMQP listener.
$ curl http://10.0.0.99:5672
curl: (56) Failure when receiving data from the peer
AMQP
It's important to distinguish between the different messages: the first failure was because curl
could not connect to the port. The second failure is a success test, though curl
expected an HTTP listener instead of an AMQP listener.
5
If curl isn't available, wget might be.wget -qS -O- http://ip.add.re.ss:port
should effectively do the same thing.
– a CVn
Jul 19 '13 at 17:52
2
This even works with a hostname, ex.curl myhost:22
.
– 에이바
Feb 25 '14 at 16:17
This may be incorrect. I am havng a tomcat service running, but getting 404 error. # curl -k 192.168.194.4:6443 <html><head><title>Apache Tomcat/7.0.34 - Error report</title><style><!--H1 --- HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - /</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>/</u></p><p><b>description</b> <u>The requested resource is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.34</h3></body></html>
– Mohammad Shahid Siddiqui
Jun 2 '15 at 6:30
See my post with similar approach.
– kenorb
Dec 30 '15 at 14:49
add a comment |
I found that curl
may get the job done in a similar way to telnet
, and curl
will even tell you which protocol the listener expects.
Construct an HTTP URI from the hostname and port as the first argument to curl
. If curl
can connect, it will report a protocol mismatch and exit (if the listener isn't a web service). If curl
cannot connect, it will time out.
For example, port 5672 on host 10.0.0.99 is either closed or blocked by a firewall:
$ curl http://10.0.0.99:5672
curl: (7) couldn't connect to host
However, from a different system, port 5672 on host 10.0.0.99 can be reached, and appears to be running an AMQP listener.
$ curl http://10.0.0.99:5672
curl: (56) Failure when receiving data from the peer
AMQP
It's important to distinguish between the different messages: the first failure was because curl
could not connect to the port. The second failure is a success test, though curl
expected an HTTP listener instead of an AMQP listener.
5
If curl isn't available, wget might be.wget -qS -O- http://ip.add.re.ss:port
should effectively do the same thing.
– a CVn
Jul 19 '13 at 17:52
2
This even works with a hostname, ex.curl myhost:22
.
– 에이바
Feb 25 '14 at 16:17
This may be incorrect. I am havng a tomcat service running, but getting 404 error. # curl -k 192.168.194.4:6443 <html><head><title>Apache Tomcat/7.0.34 - Error report</title><style><!--H1 --- HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - /</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>/</u></p><p><b>description</b> <u>The requested resource is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.34</h3></body></html>
– Mohammad Shahid Siddiqui
Jun 2 '15 at 6:30
See my post with similar approach.
– kenorb
Dec 30 '15 at 14:49
add a comment |
I found that curl
may get the job done in a similar way to telnet
, and curl
will even tell you which protocol the listener expects.
Construct an HTTP URI from the hostname and port as the first argument to curl
. If curl
can connect, it will report a protocol mismatch and exit (if the listener isn't a web service). If curl
cannot connect, it will time out.
For example, port 5672 on host 10.0.0.99 is either closed or blocked by a firewall:
$ curl http://10.0.0.99:5672
curl: (7) couldn't connect to host
However, from a different system, port 5672 on host 10.0.0.99 can be reached, and appears to be running an AMQP listener.
$ curl http://10.0.0.99:5672
curl: (56) Failure when receiving data from the peer
AMQP
It's important to distinguish between the different messages: the first failure was because curl
could not connect to the port. The second failure is a success test, though curl
expected an HTTP listener instead of an AMQP listener.
I found that curl
may get the job done in a similar way to telnet
, and curl
will even tell you which protocol the listener expects.
Construct an HTTP URI from the hostname and port as the first argument to curl
. If curl
can connect, it will report a protocol mismatch and exit (if the listener isn't a web service). If curl
cannot connect, it will time out.
For example, port 5672 on host 10.0.0.99 is either closed or blocked by a firewall:
$ curl http://10.0.0.99:5672
curl: (7) couldn't connect to host
However, from a different system, port 5672 on host 10.0.0.99 can be reached, and appears to be running an AMQP listener.
$ curl http://10.0.0.99:5672
curl: (56) Failure when receiving data from the peer
AMQP
It's important to distinguish between the different messages: the first failure was because curl
could not connect to the port. The second failure is a success test, though curl
expected an HTTP listener instead of an AMQP listener.
edited Jul 19 '13 at 17:41
answered Jul 19 '13 at 17:05
Steve HHHSteve HHH
2,99062133
2,99062133
5
If curl isn't available, wget might be.wget -qS -O- http://ip.add.re.ss:port
should effectively do the same thing.
– a CVn
Jul 19 '13 at 17:52
2
This even works with a hostname, ex.curl myhost:22
.
– 에이바
Feb 25 '14 at 16:17
This may be incorrect. I am havng a tomcat service running, but getting 404 error. # curl -k 192.168.194.4:6443 <html><head><title>Apache Tomcat/7.0.34 - Error report</title><style><!--H1 --- HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - /</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>/</u></p><p><b>description</b> <u>The requested resource is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.34</h3></body></html>
– Mohammad Shahid Siddiqui
Jun 2 '15 at 6:30
See my post with similar approach.
– kenorb
Dec 30 '15 at 14:49
add a comment |
5
If curl isn't available, wget might be.wget -qS -O- http://ip.add.re.ss:port
should effectively do the same thing.
– a CVn
Jul 19 '13 at 17:52
2
This even works with a hostname, ex.curl myhost:22
.
– 에이바
Feb 25 '14 at 16:17
This may be incorrect. I am havng a tomcat service running, but getting 404 error. # curl -k 192.168.194.4:6443 <html><head><title>Apache Tomcat/7.0.34 - Error report</title><style><!--H1 --- HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - /</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>/</u></p><p><b>description</b> <u>The requested resource is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.34</h3></body></html>
– Mohammad Shahid Siddiqui
Jun 2 '15 at 6:30
See my post with similar approach.
– kenorb
Dec 30 '15 at 14:49
5
5
If curl isn't available, wget might be.
wget -qS -O- http://ip.add.re.ss:port
should effectively do the same thing.– a CVn
Jul 19 '13 at 17:52
If curl isn't available, wget might be.
wget -qS -O- http://ip.add.re.ss:port
should effectively do the same thing.– a CVn
Jul 19 '13 at 17:52
2
2
This even works with a hostname, ex.
curl myhost:22
.– 에이바
Feb 25 '14 at 16:17
This even works with a hostname, ex.
curl myhost:22
.– 에이바
Feb 25 '14 at 16:17
This may be incorrect. I am havng a tomcat service running, but getting 404 error. # curl -k 192.168.194.4:6443 <html><head><title>Apache Tomcat/7.0.34 - Error report</title><style><!--H1 --- HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - /</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>/</u></p><p><b>description</b> <u>The requested resource is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.34</h3></body></html>
– Mohammad Shahid Siddiqui
Jun 2 '15 at 6:30
This may be incorrect. I am havng a tomcat service running, but getting 404 error. # curl -k 192.168.194.4:6443 <html><head><title>Apache Tomcat/7.0.34 - Error report</title><style><!--H1 --- HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - /</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>/</u></p><p><b>description</b> <u>The requested resource is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.34</h3></body></html>
– Mohammad Shahid Siddiqui
Jun 2 '15 at 6:30
See my post with similar approach.
– kenorb
Dec 30 '15 at 14:49
See my post with similar approach.
– kenorb
Dec 30 '15 at 14:49
add a comment |
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.193.173 6443
nc: connect to 192.168.193.173 port 6443 (tcp) failed: Connection refused
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.194.4 6443
Connection to 192.168.194.4 6443 port [tcp/sun-sr-https] succeeded!
Hope it solves your problem :)
1
Yes, this is better - timing out almost immediately for closed ports.
– Peter Mortensen
Jul 21 '15 at 12:38
1
Does this always use TCP or is there a way to get it to check UDP?
– kmoe
Jan 2 '16 at 17:09
add a comment |
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.193.173 6443
nc: connect to 192.168.193.173 port 6443 (tcp) failed: Connection refused
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.194.4 6443
Connection to 192.168.194.4 6443 port [tcp/sun-sr-https] succeeded!
Hope it solves your problem :)
1
Yes, this is better - timing out almost immediately for closed ports.
– Peter Mortensen
Jul 21 '15 at 12:38
1
Does this always use TCP or is there a way to get it to check UDP?
– kmoe
Jan 2 '16 at 17:09
add a comment |
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.193.173 6443
nc: connect to 192.168.193.173 port 6443 (tcp) failed: Connection refused
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.194.4 6443
Connection to 192.168.194.4 6443 port [tcp/sun-sr-https] succeeded!
Hope it solves your problem :)
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.193.173 6443
nc: connect to 192.168.193.173 port 6443 (tcp) failed: Connection refused
[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.194.4 6443
Connection to 192.168.194.4 6443 port [tcp/sun-sr-https] succeeded!
Hope it solves your problem :)
answered Jun 2 '15 at 6:27
Mohammad Shahid SiddiquiMohammad Shahid Siddiqui
22122
22122
1
Yes, this is better - timing out almost immediately for closed ports.
– Peter Mortensen
Jul 21 '15 at 12:38
1
Does this always use TCP or is there a way to get it to check UDP?
– kmoe
Jan 2 '16 at 17:09
add a comment |
1
Yes, this is better - timing out almost immediately for closed ports.
– Peter Mortensen
Jul 21 '15 at 12:38
1
Does this always use TCP or is there a way to get it to check UDP?
– kmoe
Jan 2 '16 at 17:09
1
1
Yes, this is better - timing out almost immediately for closed ports.
– Peter Mortensen
Jul 21 '15 at 12:38
Yes, this is better - timing out almost immediately for closed ports.
– Peter Mortensen
Jul 21 '15 at 12:38
1
1
Does this always use TCP or is there a way to get it to check UDP?
– kmoe
Jan 2 '16 at 17:09
Does this always use TCP or is there a way to get it to check UDP?
– kmoe
Jan 2 '16 at 17:09
add a comment |
Here is one-liner:
</dev/tcp/localhost/11211 && echo Port is open || echo Port is closed
using Bash syntax explained in @lornix answer.
For more info, check: Advanced Bash-Scripting Guide: Chapter 29. /dev
and /proc
.
what is the timeout for closed ports?
– Tilo
Dec 12 '18 at 17:42
add a comment |
Here is one-liner:
</dev/tcp/localhost/11211 && echo Port is open || echo Port is closed
using Bash syntax explained in @lornix answer.
For more info, check: Advanced Bash-Scripting Guide: Chapter 29. /dev
and /proc
.
what is the timeout for closed ports?
– Tilo
Dec 12 '18 at 17:42
add a comment |
Here is one-liner:
</dev/tcp/localhost/11211 && echo Port is open || echo Port is closed
using Bash syntax explained in @lornix answer.
For more info, check: Advanced Bash-Scripting Guide: Chapter 29. /dev
and /proc
.
Here is one-liner:
</dev/tcp/localhost/11211 && echo Port is open || echo Port is closed
using Bash syntax explained in @lornix answer.
For more info, check: Advanced Bash-Scripting Guide: Chapter 29. /dev
and /proc
.
edited Jul 30 '18 at 10:37
answered Mar 16 '16 at 11:21
kenorbkenorb
11.5k1580116
11.5k1580116
what is the timeout for closed ports?
– Tilo
Dec 12 '18 at 17:42
add a comment |
what is the timeout for closed ports?
– Tilo
Dec 12 '18 at 17:42
what is the timeout for closed ports?
– Tilo
Dec 12 '18 at 17:42
what is the timeout for closed ports?
– Tilo
Dec 12 '18 at 17:42
add a comment |
I was struggling for a whole day because none of these answers seemed to work for me. The problem is that the most recent version of nc
no longer has the -z
flag, whereas direct access via TCP (as according to @lornix and @slm) fails when the host is not reachable. I eventually found this page, where I finally found not one but two working examples:
nc -w1 127.0.0.1 22 </dev/null
(the
-w
flag takes care of the timeout, and the</dev/null
replaces the-z
flag)
timeout 1 bash -c '(echo > /dev/tcp/127.0.0.1/22) >/dev/null 2>&1'
(the
timeout
command takes care of the timeout, and the rest is from @slm)
Then, simply use &&
and/or ||
(or even $?
) to extract the result. Hopefully, somebody will find this information useful.
add a comment |
I was struggling for a whole day because none of these answers seemed to work for me. The problem is that the most recent version of nc
no longer has the -z
flag, whereas direct access via TCP (as according to @lornix and @slm) fails when the host is not reachable. I eventually found this page, where I finally found not one but two working examples:
nc -w1 127.0.0.1 22 </dev/null
(the
-w
flag takes care of the timeout, and the</dev/null
replaces the-z
flag)
timeout 1 bash -c '(echo > /dev/tcp/127.0.0.1/22) >/dev/null 2>&1'
(the
timeout
command takes care of the timeout, and the rest is from @slm)
Then, simply use &&
and/or ||
(or even $?
) to extract the result. Hopefully, somebody will find this information useful.
add a comment |
I was struggling for a whole day because none of these answers seemed to work for me. The problem is that the most recent version of nc
no longer has the -z
flag, whereas direct access via TCP (as according to @lornix and @slm) fails when the host is not reachable. I eventually found this page, where I finally found not one but two working examples:
nc -w1 127.0.0.1 22 </dev/null
(the
-w
flag takes care of the timeout, and the</dev/null
replaces the-z
flag)
timeout 1 bash -c '(echo > /dev/tcp/127.0.0.1/22) >/dev/null 2>&1'
(the
timeout
command takes care of the timeout, and the rest is from @slm)
Then, simply use &&
and/or ||
(or even $?
) to extract the result. Hopefully, somebody will find this information useful.
I was struggling for a whole day because none of these answers seemed to work for me. The problem is that the most recent version of nc
no longer has the -z
flag, whereas direct access via TCP (as according to @lornix and @slm) fails when the host is not reachable. I eventually found this page, where I finally found not one but two working examples:
nc -w1 127.0.0.1 22 </dev/null
(the
-w
flag takes care of the timeout, and the</dev/null
replaces the-z
flag)
timeout 1 bash -c '(echo > /dev/tcp/127.0.0.1/22) >/dev/null 2>&1'
(the
timeout
command takes care of the timeout, and the rest is from @slm)
Then, simply use &&
and/or ||
(or even $?
) to extract the result. Hopefully, somebody will find this information useful.
answered May 31 '17 at 8:45
AzukikuruAzukikuru
6111
6111
add a comment |
add a comment |
It shouldn't be available on your box, but try with nmap
.
4
nmap
is a good tool, but not available on these systems. Rather than downloadnmap
, compile it, install it to my home directory, then copy it to all the other systems, I was hoping to find a way using existing tools available in most Linux installations.
– Steve HHH
Jul 19 '13 at 17:16
add a comment |
It shouldn't be available on your box, but try with nmap
.
4
nmap
is a good tool, but not available on these systems. Rather than downloadnmap
, compile it, install it to my home directory, then copy it to all the other systems, I was hoping to find a way using existing tools available in most Linux installations.
– Steve HHH
Jul 19 '13 at 17:16
add a comment |
It shouldn't be available on your box, but try with nmap
.
It shouldn't be available on your box, but try with nmap
.
edited Jul 21 '15 at 11:28
Peter Mortensen
8,376166185
8,376166185
answered Jul 19 '13 at 17:01
peperunaspeperunas
4462815
4462815
4
nmap
is a good tool, but not available on these systems. Rather than downloadnmap
, compile it, install it to my home directory, then copy it to all the other systems, I was hoping to find a way using existing tools available in most Linux installations.
– Steve HHH
Jul 19 '13 at 17:16
add a comment |
4
nmap
is a good tool, but not available on these systems. Rather than downloadnmap
, compile it, install it to my home directory, then copy it to all the other systems, I was hoping to find a way using existing tools available in most Linux installations.
– Steve HHH
Jul 19 '13 at 17:16
4
4
nmap
is a good tool, but not available on these systems. Rather than download nmap
, compile it, install it to my home directory, then copy it to all the other systems, I was hoping to find a way using existing tools available in most Linux installations.– Steve HHH
Jul 19 '13 at 17:16
nmap
is a good tool, but not available on these systems. Rather than download nmap
, compile it, install it to my home directory, then copy it to all the other systems, I was hoping to find a way using existing tools available in most Linux installations.– Steve HHH
Jul 19 '13 at 17:16
add a comment |
Here's a function that will pick one of the methods depending on what's installed on your system:
# Check_port <address> <port>
check_port() {
if [ "$(which nc)" != "" ]; then
tool=nc
elif [ "$(which curl)" != "" ]; then
tool=curl
elif [ "$(which telnet)" != "" ]; then
tool=telnet
elif [ -e /dev/tcp ]; then
if [ "$(which gtimeout)" != "" ]; then
tool=gtimeout
elif [ "$(which timeout)" != "" ]; then
tool=timeout
else
tool=devtcp
fi
fi
echo "Using $tool to test access to $1:$2"
case $tool in
nc) nc -v -G 5 -z -w2 $1 $2 ;;
curl) curl --connect-timeout 10 http://$1:$2 ;;
telnet) telnet $1 $2 ;;
gtimeout) gtimeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
timeout) timeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
devtcp) </dev/tcp/${1}/${2} && echo Port is open || echo Port is closed ;;
*) echo "no tools available to test $1 port $2";;
esac
}
export check_port
add a comment |
Here's a function that will pick one of the methods depending on what's installed on your system:
# Check_port <address> <port>
check_port() {
if [ "$(which nc)" != "" ]; then
tool=nc
elif [ "$(which curl)" != "" ]; then
tool=curl
elif [ "$(which telnet)" != "" ]; then
tool=telnet
elif [ -e /dev/tcp ]; then
if [ "$(which gtimeout)" != "" ]; then
tool=gtimeout
elif [ "$(which timeout)" != "" ]; then
tool=timeout
else
tool=devtcp
fi
fi
echo "Using $tool to test access to $1:$2"
case $tool in
nc) nc -v -G 5 -z -w2 $1 $2 ;;
curl) curl --connect-timeout 10 http://$1:$2 ;;
telnet) telnet $1 $2 ;;
gtimeout) gtimeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
timeout) timeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
devtcp) </dev/tcp/${1}/${2} && echo Port is open || echo Port is closed ;;
*) echo "no tools available to test $1 port $2";;
esac
}
export check_port
add a comment |
Here's a function that will pick one of the methods depending on what's installed on your system:
# Check_port <address> <port>
check_port() {
if [ "$(which nc)" != "" ]; then
tool=nc
elif [ "$(which curl)" != "" ]; then
tool=curl
elif [ "$(which telnet)" != "" ]; then
tool=telnet
elif [ -e /dev/tcp ]; then
if [ "$(which gtimeout)" != "" ]; then
tool=gtimeout
elif [ "$(which timeout)" != "" ]; then
tool=timeout
else
tool=devtcp
fi
fi
echo "Using $tool to test access to $1:$2"
case $tool in
nc) nc -v -G 5 -z -w2 $1 $2 ;;
curl) curl --connect-timeout 10 http://$1:$2 ;;
telnet) telnet $1 $2 ;;
gtimeout) gtimeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
timeout) timeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
devtcp) </dev/tcp/${1}/${2} && echo Port is open || echo Port is closed ;;
*) echo "no tools available to test $1 port $2";;
esac
}
export check_port
Here's a function that will pick one of the methods depending on what's installed on your system:
# Check_port <address> <port>
check_port() {
if [ "$(which nc)" != "" ]; then
tool=nc
elif [ "$(which curl)" != "" ]; then
tool=curl
elif [ "$(which telnet)" != "" ]; then
tool=telnet
elif [ -e /dev/tcp ]; then
if [ "$(which gtimeout)" != "" ]; then
tool=gtimeout
elif [ "$(which timeout)" != "" ]; then
tool=timeout
else
tool=devtcp
fi
fi
echo "Using $tool to test access to $1:$2"
case $tool in
nc) nc -v -G 5 -z -w2 $1 $2 ;;
curl) curl --connect-timeout 10 http://$1:$2 ;;
telnet) telnet $1 $2 ;;
gtimeout) gtimeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
timeout) timeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
devtcp) </dev/tcp/${1}/${2} && echo Port is open || echo Port is closed ;;
*) echo "no tools available to test $1 port $2";;
esac
}
export check_port
answered Feb 12 at 20:21
Robert BoydRobert Boyd
111
111
add a comment |
add a comment |
Combining the answers from @kenorb and @Azukikuru you could test port open/closed/firewalled.
timeout 1 bash -c '</dev/tcp/127.0.0.1/22 && echo Port is open || echo Port is closed' || echo Connection timeout
Another approach with curl for reaching any port
curl telnet://127.0.0.1:22
add a comment |
Combining the answers from @kenorb and @Azukikuru you could test port open/closed/firewalled.
timeout 1 bash -c '</dev/tcp/127.0.0.1/22 && echo Port is open || echo Port is closed' || echo Connection timeout
Another approach with curl for reaching any port
curl telnet://127.0.0.1:22
add a comment |
Combining the answers from @kenorb and @Azukikuru you could test port open/closed/firewalled.
timeout 1 bash -c '</dev/tcp/127.0.0.1/22 && echo Port is open || echo Port is closed' || echo Connection timeout
Another approach with curl for reaching any port
curl telnet://127.0.0.1:22
Combining the answers from @kenorb and @Azukikuru you could test port open/closed/firewalled.
timeout 1 bash -c '</dev/tcp/127.0.0.1/22 && echo Port is open || echo Port is closed' || echo Connection timeout
Another approach with curl for reaching any port
curl telnet://127.0.0.1:22
edited Aug 12 '18 at 16:54
answered Aug 10 '18 at 12:20
Miguel FerreiraMiguel Ferreira
1012
1012
add a comment |
add a comment |
If you've to test more than on system you may use our test tool dda-serverspec (https://github.com/DomainDrivenArchitecture/dda-serverspec-crate) for such tasks. You may define your expectation
{:netcat [{:host "mywebserver.com" :port "443"}
{:host "telnet mywebserver.com" :port "80"}
{:host "telnet mywebserver.com" :port "8443"}]}
and test these expectation either against localhost or against remote hosts (connect by ssh). For remote tests you've to define a targets:
{:existing [{:node-name "test-vm1"
:node-ip "35.157.19.218"}
{:node-name "test-vm2"
:node-ip "18.194.113.138"}]
:provisioning-user {:login "ubuntu"}}
You may run the test with java -jar dda-serverspec.jar --targets targets.edn serverspec.edn
Under the hood we're using netcat as proprosed above ...
add a comment |
If you've to test more than on system you may use our test tool dda-serverspec (https://github.com/DomainDrivenArchitecture/dda-serverspec-crate) for such tasks. You may define your expectation
{:netcat [{:host "mywebserver.com" :port "443"}
{:host "telnet mywebserver.com" :port "80"}
{:host "telnet mywebserver.com" :port "8443"}]}
and test these expectation either against localhost or against remote hosts (connect by ssh). For remote tests you've to define a targets:
{:existing [{:node-name "test-vm1"
:node-ip "35.157.19.218"}
{:node-name "test-vm2"
:node-ip "18.194.113.138"}]
:provisioning-user {:login "ubuntu"}}
You may run the test with java -jar dda-serverspec.jar --targets targets.edn serverspec.edn
Under the hood we're using netcat as proprosed above ...
add a comment |
If you've to test more than on system you may use our test tool dda-serverspec (https://github.com/DomainDrivenArchitecture/dda-serverspec-crate) for such tasks. You may define your expectation
{:netcat [{:host "mywebserver.com" :port "443"}
{:host "telnet mywebserver.com" :port "80"}
{:host "telnet mywebserver.com" :port "8443"}]}
and test these expectation either against localhost or against remote hosts (connect by ssh). For remote tests you've to define a targets:
{:existing [{:node-name "test-vm1"
:node-ip "35.157.19.218"}
{:node-name "test-vm2"
:node-ip "18.194.113.138"}]
:provisioning-user {:login "ubuntu"}}
You may run the test with java -jar dda-serverspec.jar --targets targets.edn serverspec.edn
Under the hood we're using netcat as proprosed above ...
If you've to test more than on system you may use our test tool dda-serverspec (https://github.com/DomainDrivenArchitecture/dda-serverspec-crate) for such tasks. You may define your expectation
{:netcat [{:host "mywebserver.com" :port "443"}
{:host "telnet mywebserver.com" :port "80"}
{:host "telnet mywebserver.com" :port "8443"}]}
and test these expectation either against localhost or against remote hosts (connect by ssh). For remote tests you've to define a targets:
{:existing [{:node-name "test-vm1"
:node-ip "35.157.19.218"}
{:node-name "test-vm2"
:node-ip "18.194.113.138"}]
:provisioning-user {:login "ubuntu"}}
You may run the test with java -jar dda-serverspec.jar --targets targets.edn serverspec.edn
Under the hood we're using netcat as proprosed above ...
answered Oct 26 '18 at 13:49
jergerjerger
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f621870%2ftest-if-a-port-on-a-remote-system-is-reachable-without-telnet%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Related: check status of one port on remote host at SO
– kenorb
Dec 30 '15 at 14:50