Nmap Development mailing list archives
Re: Raw IP NSE Functionality
From: Patrick Donnelly <batrick () batbytes com>
Date: Tue, 23 Feb 2010 14:39:01 -0500
On Tue, Feb 23, 2010 at 1:49 PM, Patrick Donnelly <batrick () batbytes com> wrote:
Hi David, On Tue, Feb 23, 2010 at 3:07 AM, David Fifield <david () bamsoftware com> wrote:On Wed, Feb 17, 2010 at 10:35:04PM -0500, Patrick Donnelly wrote:On Wed, Feb 17, 2010 at 8:16 PM, David Fifield <david () bamsoftware com> wrote:The nmap.is_privileged function I have no objection to. All the above is fine with me. One thing deserves some further design discussion, which is the nmap.get_ports function. I think it would be better to wrap PortList::nextPort more directly, giving scripts one-at-a-time access to port tables (and avoiding creating a potentially large table of tables, most of which won't be used by many scripts). A script that needs the full port list can easily create it by doing just what your C function does, looping with nextPort. Scripts like ipidseq.nse that need just any old port wouldn't need to allocate as much memory.NSE currently iterates over the port tables in the same way Kris does (create a large array of port tables). We can move to the other approach but we will need to have some "complicated" userdata for the for loop invariant (see generic for loops [1]). If we do this it should be generic enough so that NSE can use it too. I can do this if Kris doesn't want to.Okay. I see that cnse.ports does just as you say (ports function in nse_main.cc). Let's handle one thing at a time. If you or Kris can implement a user-level interface around nextPort, let's do that first so that the raw IP stuff can be merged. Then reworking nse_main.lua to use less memory while iterating over the port table can be handled as a separate step. I'm not so much concerned about the implementation right now as the interface. If cnse and script-level NSE use different methods to access the ports, that's fine for now. The internal implementation can change later.I attached a patch against the nmap trunk that does this.
Ok this patch wasn't quite right. I've attached a new one but I'm getting some strange C++ segfault I can't figure out. I'm not going to devote any more time to this since Kris has a viable patch already committed. -- - Patrick Donnelly
Attachment:
getports.2.patch
Description:
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Raw IP NSE Functionality (Was Re: [NSE] Raw ethernet frame questions ...), (continued)
- Re: Raw IP NSE Functionality (Was Re: [NSE] Raw ethernet frame questions ...) Kris Katterjohn (Feb 17)
- error compiling 5.21 Mike Calmus (Feb 20)
- Re: error compiling 5.21 David Fifield (Feb 22)
- Re: error compiling 5.21 Mike Calmus (Feb 23)
- Re: Raw IP NSE Functionality (Was Re: [NSE] Raw ethernet frame questions ...) Patrick Donnelly (Feb 17)
- Re: Raw IP NSE Functionality (Was Re: [NSE] Raw ethernet frame questions ...) Kris Katterjohn (Feb 17)
- Re: Raw IP NSE Functionality David Fifield (Feb 23)
- Re: Raw IP NSE Functionality Patrick Donnelly (Feb 23)
- Re: Raw IP NSE Functionality Patrick Donnelly (Feb 23)
- Re: Raw IP NSE Functionality Kris Katterjohn (Feb 23)
- Re: Raw IP NSE Functionality David Fifield (Feb 23)
- Re: Raw IP NSE Functionality David Fifield (Feb 25)
- Re: Raw IP NSE Functionality Kris Katterjohn (Feb 25)
- pcap_register David Fifield (Feb 25)
- Re: pcap_register majek04 (Feb 26)
- Re: pcap_register Kris Katterjohn (Feb 26)
- Re: Raw IP NSE Functionality kx (Feb 25)
- Re: Raw IP NSE Functionality David Fifield (Feb 25)
- Re: Raw IP NSE Functionality Kris Katterjohn (Feb 26)