I do not have access to netcat or nmap so I'm trying to use bash and the /dev/udp/ special files to test ports.

I could do something like:

echo "" > /dev/udp/example.com/8000

But $? is always 0 when using UDP. I'm assuming that's because that is the return value of the echo "" command correct?

I am basically trying to replicate what I am able to do with nmap and netcat:

nmap -sU -p 8000 example.com | grep open >/dev/null && echo 'open'
nc -z -u example.com 8000 && echo 'open'

How would I do this with /dev/udp?

  • 1
    UDP doesn't guarantee delivery, so even if bash thinks it's succeeded in sending the message, the message may have been destroyed on the way. How did you test an unsuccessful sending (not an unsuccessful connection: UDP isn't a connection)? – Gilles Mar 21 '15 at 18:59

For tcp, just checking $?. If connection failed, $? won't be 0:

$ >/dev/tcp/google.com/81
bash: connect: Network is unreachable
bash: /dev/tcp/google.com/81: Network is unreachable
$ echo $?

It will take time for bash to realize that the connection failed. You can use timeout to trigger bash:

$ timeout 1 bash -c '>/dev/tcp/google.com/80' &&
  echo Port open ||
  echo Port close
Port open

Testing udp port is more complex.

Strictly speaking, there is no open state (of course, udp is stateless protocol) with udp. There're only two states with udp, listening or not. If the state is not, you will get an ICMP Destination Unreachable.

Unfortunately, firewall or router often drop those ICMP packets, so you won't be sure what state of udp port.

  • Rephrased my question to focus on UDP. My apologies for the ninja edit. I thought it would be similar so did not make the distinction. Thanks for clearing it up. – Belmin Fernandez Mar 21 '15 at 19:08

In general, you can't.

Unlike TCP, UDP is connectionless. You can't detect that a port is open simply by making a do-nothing connection to it like you can with TCP. Rather, you need to send data to the port and see what happens, and the details of UDP as implemented in the real world make interpreting the results difficult. Even sophisticated packet-level tools like nmap can't tell for certain if there's a program listening to a given UDP port. nmap classifies UDP ports into three groups:

  1. Definitely open. Sending a packet to the port elicited a data response from the destination machine.
  2. Definitely closed. Sending a packet to the port elicited a "ICMP Destination Unreachable" message from the destination machine.
  3. Either open or filtered. Sending a packet to the port elicited no response whatsoever. Maybe there's a firewall that's dropping the packets; maybe there's a program listening and nmap just hasn't figured out how to get a response; maybe the user just got unlucky and all the packets were lost in transit.
  • Great information about nmap. Thanks, this clarifies a lot of confusion. – Belmin Fernandez Mar 22 '15 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.