Re: exclude targets

[David Fifield <david () bamsoftware com>]

On Sat, Nov 07, 2009 at 02:34:47PM +0100, Si Stransky wrote:
> 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.

Thank you for this report and for the excellent test cases. I solved the
problem in r16120. The problem was in an optimization to exclude groups
that could fail when there wasn't a range in the final octet. After
checking the exclude address 10.10.250.22 in the range 10.10.250-255.22
for example, the address would skip ahead to 10.10.252.22 instead of
10.10.251.22. This caused the internal count to get out of sync.

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