Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3)

[David Fifield <david () bamsoftware com>]

On Tue, Sep 18, 2012 at 02:18:23PM -0400, Brendan Byrd wrote:
> On Tue, Sep 18, 2012 at 11:59 AM, David Fifield <david () bamsoftware com> wrote:
> > Either way is fine, but it is important not to include these stylistic
> > changes in patches that change functionality.
>
> Okay, here's the tweaked patch.

Thank you for doing this. I'm still disinclined to take the patch. I
don't see the need for it, apart from the SNMP changes which I didn't
quite understand and which have dropped off my radar. (You can resend
those if you think they've been unfairly overlooked.)

This patch seems to be working correctly. At least, I tried
        ipOps.get_ranges_from_ips("0.0.0.1", "255.255.255.254")
and it seemed to do the right thing.

Also, I think we may be approaching this the wrong way. I don't think
that lists of ranges is the best way to represent a set of addresses
like this. The problem you're trying to solve is not "manage a bunch of
CIDR ranges," it's "prevent addresses from being scanned twice," which
to me is really "have a space-efficient data structure representing a
set of addresses, in which insertion and testing for membership are
fast, possibly using the assumption that some insertions will be
contiguous blocks of addresses."

We already have to do a similar thing with Nmap's --exclude list, and
for that we use a structure called an addrset from Nbase. It's not quite
suitable for preventing duplicates because it does set union by adding
elements to a list. But I think it has a better level of abstraction: I
want to say
        remember_i_already_scanned_this("192.168.0.0/24")
and not think about a list of ranges.

Brandon Enright has criticized the performance of addrset on large
exclude lists; maybe he has ideas for a better representation that would
serve the duplicates purpose as well.

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