Nmap Development: exclude targets (original) (raw)

nmap-dev logo

Nmap Developmentmailing list archives

From: Si Stransky <gmeildeno () gmail com>
Date: Sat, 7 Nov 2009 14:34:47 +0100

My salutations to all nmap followers,

I have something going wrong with certain sorts of exclude targets.. see for example

$ nmap -sL -n --exclude 10.0-253.0.1 10.250-255.0.22 .. nmap: TargetGroup.cc:459: int TargetGroup::get_next_host(sockaddr_storage*, size_t*): Assertion `ipsleft == 1' failed. Aborted

$ nmap -sL -n -q --exclude 10.10.250-255.22 10.10.250-255.0-255 .. pine: TargetGroup.cc:459: int TargetGroup::get_next_host(sockaddr_storage*, size_t*): Assertion `ipsleft == 1' failed. Aborted

$ nmap -sL -n -q --exclude 10.10.250-254.22 10.10.250-255.0-255 .. pine: TargetGroup.cc:465: int TargetGroup::get_next_host(sockaddr_storage*, size_t*): Assertion `ipsleft > 1' failed. Aborted

$ nmap -sL -n -q --exclude *.10.250-255.22 10.10.250-255.0-255 .. pine: TargetGroup.cc:372: int TargetGroup::skip_range(TargetGroup::_octet_nums): Assertion `ipsleft

Apart from the last example where the exclude range is actually greater than the whole scanning range and should be a discouraged use of the exclude option since it makes nmap calculate unneeded IPs, the others should be and actually are proper forms.

========== In these outputs I noticed error messages that either begin with nmap: other times with pine: or ne: other with nothing in particular. Here it seems that if nmap is called from different paths with -q there is a different behaviour, maybe something wrong is set in my 'env'? $ ./nmap -sL -n -q --exclude 10.10.250-255.22 10.10.250-255.0-255

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-07 12:13 CET ne: TargetGroup.cc:459: int TargetGroup::get_next_host(sockaddr_storage*, size_t*): Assertion `ipsleft == 1' failed. Aborted

$ /usr/local/bin/nmap -sL -n -q --exclude 10.10.250-255.22 10.10.250-255.0-255

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-07 12:12 CET TargetGroup.cc:459: int TargetGroup::get_next_host(sockaddr_storage*, size_t*): Assertion `ipsleft == 1 ' failed. Aborted

$ nmap -sL -n -q --exclude 10.10.250-255.22 10.10.250-255.0-255

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-07 12:12 CET pine: TargetGroup.cc:459: int TargetGroup::get_next_host(sockaddr_storage*, size_t*): Assertion `ipsleft == 1' failed. Aborted

I believe it has something to do with argv around these lines: nmap$ grep -n "FAKE_ARGV" * nmap.cc:1596: size_t fakeargvlen = strlen(FAKE_ARGV), argvlen = strlen(argv[0]); nmap.cc:1599: strncpy(argv[0], FAKE_ARGV, fakeargvlen); nmap.h:265:#define FAKE_ARGV "pine" /* What ps and w should show if you use -q */

======== Are --exclude --excludefile supposed to actually work with random scan -iR x? If not it should be forbidden to call such command (warn user and gracefully exit) I noticed there is a thing when excluding very large netblocks in a random scan: the thing is that if -for example- 300 IPs are requested from command line (-iR 300) and there is an exclusion (--exclude bignetblock) it may happen that the hosts actually scanned are less than 300; the count on randomly generated IPs seems to be made before leaving out excluded hosts. I really don't know if it would make sense to fix it, so that the check would be made after having excluded unwanted hosts, resulting in the exact number of hosts requested from command (if enough IPs are left unexcluded of course).

Another handy feature would be having the possibility to include only a range of hosts in the random scan. Something like: nmap -iR n 10.198.250-255.0-255 should scan, from a fixed pool of IPs, n number of hosts always 'randomly different' every time it is called. Combining the two features - including hosts, excluding hosts -and random processing a fixed max number of hosts (or even all, as -iR 0) would make nmap even more versatile but I understand from the code that it would need too many things rewrited as for target parsing, calculating and random generation, so as I am only a casual user I give up. What do you think about patching it?

Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/

Current thread: