I am working on a bash script to enable automatic detection and remote control of my company's proprietary data recorders. The recorders run a custom version of linux and are essentially powerful pis or arduinos.

The ethernet port on the devices is configured so that when plugged into the network, it will be given a dhcp lease. In order to detect the devices, I am monitoring /var/lib/dhcp/dhcpd.leases on my local machine. For each unique entry, I portscan to test for ssh server status using nmap. To enable an automatic launch of this script, it is being called from /etc/rc3.d/rc.local and thus is run by root on boot time. This is where things get strange.

To make sure that we can always detect new connections, the dhcpd.leases file is checked in an infinite loop. We also want to keep a low system footprint so in order to cut down the time of each loop iteration, we impose a small timeout on our nmap. Here is the exact line in use:

nmap --max-retries=1 -p 22 --host-timeout=50ms $ip_address

When run as a normal user this line works incredibly consistently, but as root, I have to increase to timeout to 600ms for consistently positive results. I've tested it using the time command and here is a usual result (done with a 600ms timeout):

Starting Nmap 6.40 ( http://nmap.org ) at 2014-12-19 09:41 EST
Nmap scan report for
Host is up (0.00039s latency).
22/tcp  open  ssh

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

real    0m0.059s
user    0m0.043s
sys     0m0.004s

Here is the output for the same thing, but logged in as root:

Starting Nmap 6.40 ( http://nmap.org ) at 2014-12-19 09:48 EST
Nmap scan report for
Host is up (0.00035s latency).
22/tcp  open  ssh
MAC Address: 00:04:D1:0B:03:EC

Nmap done: 1 IP address (1 host up) scanned in 0.55 seconds

real    0m0.580s
user    0m0.056s
sys     0m0.008s

Any ideas what could be causing this extra time and how to prevent it? From some preliminary research, I can see that root runs with some set defaults that other users don't have access to. How can I go about replicating the conditions of nmap being executed by a normal user?

As an additional note, this is being run on an Ubuntu 14.04 LTS machine.


After further research, I found something of interest in the MISC section of the man page. There is a option for --unprivileged which forces operation as a normal user, even as root. This performs significantly less operations and provides less info back, but if all you are doing is checking for ssh on port 22, it does it as fast as possible.


I'm not sure what would be causing the difference in the two runs, but I have some ideas for consistency and speed which may help. First, here are the differences in operations between root and non-root scans with the options you selected:

  • Unprivileged (non-root) scans will use a pair of TCP connect() calls to determine if the host is up; root scans will send an ARP request and sniff the network for the response. The ARP request should be faster, since the connect calls require the OS to perform:
    1. an ARP request, or at least an ARP cache lookup
    2. at least another round-trip to get a response from the target
  • Non-root scans will use a full TCP connect() call to scan port 22, and must close down the socket when done; root scans will perform a half-handshake, relying on the OS to close the connection "in the background."

So with these options, generally a privileged scan will be faster. However, with a very low-latency network connection, it's possible that the setup of the various PCAP listeners would slow a root scan down a little. But that's probably not where your delay is coming from.

You can speed up your scan by skipping some of the scan phases that you don't need. Try adding the -n flag to skip the reverse name lookup (which doesn't count towards the host timeout, by the way!). Or if you know the target is present and only want to check for the port 22 response, add the -Pn option to skip the host discovery phase.

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.