Re: Raw IP NSE Functionality

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/25/2010 04:03 PM, David Fifield wrote:
> I have this fixed in r16879. Man, you had me deep in the Nsock pcap code
> before I thought to look at this:
>
> --- scripts/ipidseq.nse (revision 16878)
> +++ scripts/ipidseq.nse (revision 16879)
> @@ -215,8 +215,6 @@
>
>         pcap:set_timeout(3000)
>
> -       math.randomseed(os.time())
> -
>         local tcp = genericpkt(host, port)
>
>         while i <= NUMPROBES do

Well damn, that wasn't very climactic.. or was it? ;)

Yesterday and today I managed to get some afternoon spurts of debugging in,
and while in the middle of it today, I smacked my forehead when I saw your
commit mail.  I have piles of various debugging output statements, saved
outputs and some packet captures which I should just save for a good laugh
later :)

Thanks, David!

> os.time has a resolution of one second, so most of the time both scripts
> had the same random seed. The first random number they generated was the
> source port for the first probe, which would be the same in both
> scripts. Therefore both scripts registered the same pcap key and both
> saw the same one out of the two reply packets. The fe times when there
> was no collision, the two calls to math.randomseed must have fallen on
> either side of a second boundary.

See, it always occurred for me.  I was wondering why (and now how) it happened
without fail for me, but you saw otherwise.

> The BPF filter alone won't prohibit one script from receiving another
> script's packets. As I understand it, that's the purpose of the extra
> pcap_register step. You could make the matching more robust by
> registering all the information that you currently have in the BPF,
> which is the source and destination hosts as well as the source port.

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?  Matching source ports or not, I don't think it should
happen because of the different address *in the filter*.  It's all raw packets
here, so I don't grasp why this isn't done.

I thought the pcap_register() bit was like additional filtering, after the
processing pcap does with its BPF filter.  I thought it was very useful when
things change, like the source port in the script, but only if (as I imagined)
it happens after pcap's filtering.

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?

> This all looks good an ready to merge, once you add documentation for
> the nmap.get_ports function to nmap.luadoc and scripting.xml.

Great!  I'll try to write it up and commit it tonight.

> David Fifield

Thanks,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJLhvt7AAoJEEQxgFs5kUfuouYP/iwrqlMaGe//ZeglmX7ct2Kn
rrWV3CDCdyLLvkDsTtLIkvzgPkGVd4ok0MuFajGlkRntPMW5Oqy8UbRHcZ31PfRA
nnxTnQOie+N/AOVn62diRwxb7WW+UOHoUZwt4Japwjz7nC2uCwAzAaaua2qdFOHm
SuTJ60Kb0OLYkKHOuWEbQnElbm6Rn9MWUpGe7KBngPRAN32CA4lsbrEkVy4UWIvc
8Ni3l3q2bs1Jt08enGDbFnMqQdGeHQ6bsquU8CvLFcT96YpmTnl74c6Nr30YeefO
3sf43ucKglN7OLjK53WIyGRkM73V2n/jXz7QLSVfqPplpq98N33F0uhxXke0vaoh
Fc3qzPJUstPvuMCGiYFf0obaEOOdSyeRjJD/fO1nGPGAZKb+ekO+hiQxvRUw7jAQ
Cv0gtW/7gi2PBZrmPi/+cGgw5hCvjZ3dOcwImOJGEpFoBIlHewlOXZ7LlTbu2OrU
WDViTsNczf1mx6SFCRuaxkUPBmkaCrejH2HjvvyrtvtTY7XB9bUgK2YM5wDVn2oR
c172ho62JQxOn2t+hYqFQefmyCRxfVoV2hxnKW8G4Mn8f3VBFk24NMdffosNGdv8
5qkZNp91ZvY84DcfI7rQblKE8YQy8YGzn0ij1/8KVNNCO4VNIaAJNSjEjfmUOi0W
MPeJwQfrXfbdb87UvWS2
=1J8T
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/