Nmap Development mailing list archives
Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3)
From: David Fifield <david () bamsoftware com>
Date: Tue, 18 Sep 2012 12:08:51 -0700
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/
Current thread:
- CIDR range capabilities for ipOps (NSE Leftovers - Part 3) Brendan Byrd (Aug 21)
- Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3) David Fifield (Sep 06)
- <Possible follow-ups>
- Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3) Brendan Byrd (Sep 18)
- Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3) David Fifield (Sep 18)
- Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3) Brendan Byrd (Sep 18)
- Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3) David Fifield (Sep 18)
- Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3) Brendan Byrd (Sep 18)
- Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3) David Fifield (Sep 18)
- Re: CIDR range capabilities for ipOps (NSE Leftovers - Part 3) David Fifield (Sep 18)