nc (netcat) on Mac OS X 10.8.4 gets stuck

Question

I encountered a little issue while using the nc utility on Mac OS X, a utility i often use as a quick and dirty solution to check if a port is open and what version the daemon is running.

We deployed a new set of computers the other day and i wanted to verify what version of sshd they were running, without having to leave my chair.

This is the command i ran and the resulting output:

$ for i in {183..200}; do echo "hello" | nc -n -w 2 -v 10.120.113.$i 22; done
Connection to 10.120.113.183 22 port [tcp/*] succeeded!
SSH-2.0-OpenSSH_5.9
Protocol mismatch.
nc: connect to 10.120.113.184 port 22 (tcp) failed: Connection refused
^C
$

It finds the first machine on 183 and returns the daemon version, it dont look like the sshd is running on 184, but when it hits 185 it simply stops and i have to kill it with ctrl+c.

As i have understood the man page for nc it should time out when using the '-w' switch, but it don't. Its the same issue from multiple machines.

Is this simply the case of me misunderstanding the man page? Is there any other way to make nc time out after X seconds if don´t receive any response? Is there any other way to do this using the builtin tools in Mac OS X?

I´ve also tried running nc with only the '-z' switch with the same results. The machines are placed in our production so i´m not allowed to install any 3rd party applications like nmap.

Platform: Mac OS X 10.8.4
Executable: /usr/bin/nc

Sorry if this question has been answered, i searched but could not find any solution to this.

Hellespont

I think there's a bug in nc on the Mac. I have Yosemite. When I compare the same command on Linux for DNS proxying, Linux returns the response over and over like it should. On the Mac, it returns the first response and then jams because I assume it's not seeing the end of the transmission. See for yourself with mkfifo /tmp/fifo; nc -lu 127.0.0.1 53 < /tmp/fifo | nc -u 8.8.4.4 53 > /tmp/fifo and then in another terminal window, do nslookup example.com 127.0.0.1 more than once. – Bantling

Answer 1

I believe you are looking for the -G option. From the man pages:

-G conntimeout TCP connection timeout in seconds.

-w is used to set the timeout after connection. -G option is used to set the timeout before connection. This should give you what you want

nc -n -G 2 -v xxx.xxx.xxx.xxx 22

Snaffle

Answer 2

I tried this on my Mac running 10.8.4 and after about 6 minutes it was looking like:

andys-MacBook-Pro:EquipDB uw$ for i in {183..200}; do echo "hello" | nc -n -w 2 -v 10.120.113.$i 22; done
nc: connect to 10.120.113.183 port 22 (tcp) failed: Operation timed out
nc: connect to 10.120.113.184 port 22 (tcp) failed: Operation timed out
nc: connect to 10.120.113.185 port 22 (tcp) failed: Operation timed out
nc: connect to 10.120.113.185 port 22 (tcp) failed: Operation timed out

So it is timing out on mine, but just takes quite a while.

Hmmm... was thinking my test would be pointless because I will never actually connect to something since I'm not on your network. But I did see this:

-w # => Timeout after # seconds

Note that -w also sets the network inactivity timeout. This does not have any effect until standard input closes, but then if nothing further arrives from the network in the next seconds, netcat tries to read the net once more for good measure, and then closes and exits. There are a lot of network services now that accept a small amount of input and return a large amount of output, such as Gopher and Web servers, which is the main reason netcat was written to ``block'' on the network staying open rather than standard input. Handling the timeout this way gives uniform behavior with network servers that don't close by themselves until told to.

This works for final net reads but not for connections.

If I'm understanding this right it only times out once it connects, since mine never connects it just has a built in timeout that has nothing to do with -w? found here, helpful?

Kazimir

Thanks for the reply. I noticed the same thing, nc seems to timeout after aprox. 90sec. I guess the question now is if there is any way to force nc to time out in less than that. – Hellespont

Decided to write a little script that updates the arp cache on my client before checking open ports/service versions, this will provide me with a list of used IP addresses. In addition to that i´ll push out an update version of the custom startup script that will prevent the users from disabling sshd trough System Preferences. This should prevent nc from connecting to non-existing IP addresses and clients with sshd turned off. I know it wont actually solve the issue, but i really appreciated your feedback tho, thanks Beartech! – Hellespont

The -G flag on Mac is TCP connection timeout in seconds for nc – Priggery