Re: pcap_register

[majek04 <majek04 () gmail com>]

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/