Nmap Development mailing list archives
Re: pcap_register
From: majek04 <majek04 () gmail com>
Date: Fri, 26 Feb 2010 11:59:12 +0000
I haven't been following the whole discussion, so excuse me if I answer the wrong questions.
On Thu, Feb 25, 2010 at 04:36:44PM -0600, Kris Katterjohn wrote:I'm not understanding the purposefulness of this. Why is one script with a filter for one host still getting packets from another host responding to a different script?
Okay. Let's assume for a while that every NSE script is opening new pcap descriptor. Implications of that are severe: - we might have few hundred opened pcap descriptors in the same time. - we have no clue how operating system implements them - is the complexity linear? If so, that means that every packet needs to go through several hundred BPF filters. That's rather bad. - next thing is latency - next thing is that pcap descriptors aren't selectable - so having few hundred of them in nsock loop will really be inefficient. Consider code in nmap core, for example SYN scan. We open one file descriptor to catch all the SYN packets. If we have less than 20 hosts, we hardcode their ip-addresses in the BPF, if more, than we catch every possible SYN packet and do the dispatching ourselves. That's exactly how the Pcap infrastructure is done in NSE. We open one pcap descriptor for a script type, with one BPF. This BPF should be generic enough to catch everything for all the scripts of this kind. So I want one pcap descriptor for the .nse script file. Hopefully, I assume that we won't have few hundreds of scripts that use pcap. Than, after BPF is hooked into the machinery, we actually do the pcap_register() which tells: "oh, btw. this particular script is interested only in packets that match this signature".
On Thu, Feb 25, 2010 at 04:36:44PM -0600, Kris Katterjohn wrote:In this regard, I wanted to put as much in the BPF filter as I could to reduce the pcap_register() stuff, so if the filter doesn't really filter for the script, I must ask: what's the point of having both? Or better yet: what advantages does the current way present?
You can do that. The machinery don't stop you from creating a specific BPF for every instance of a script. It just won't scale. Especially on windows. Oh, and it can slow down your machine. (as kernel needs to do additional work for every packet for every BPF) Does that answer your questions? Cheers! Marek Majkowski _______________________________________________ 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 ...) 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)