Nmap Development mailing list archives

exclude targets


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
+ 1>= hosts_skipped' failed.
Aborted

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: