Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [NSE] WHOIS - Now with Queuing and Cached Results.
From: "Patrick Donnelly" <batrick.donnelly () gmail com>
Date: Sat, 14 Jun 2008 22:17:59 -0600

On Sat, Jun 14, 2008 at 8:16 PM, jah <jah () zadkiel plus com> wrote:
On 14/06/2008 02:54, Fyodor wrote:
Hi Jah.  Patrick has recently added mutex support to his branch in
order to support this sort of feature:

http://seclists.org/nmap-dev/2008/q2/0620.html

The feature is documented here:

http://nmap.org/book/nse-api.html#nse-mutex

And is available in his branch in svn://svn.insecure.org/nmap-exp/patrick

Maybe you could try implementing whois.nse with this new feature?  It
seems much cleaner than the pcap hack (or even than a sleep function
would be).
Hello,

It is a cool feature!  I still haven't finished, but I wanted to
bring-up something I've noticed.  That is the order in which coroutines
resume (after the lock on "id" is removed) which, in Patrick's branch,
isn't the same order as the targets specified on the command line.
The reason it's notable from the perspective of whois.nse is that for
several targets in the same range the coroutine that actually finds the
record and which is pointed to in the Host Script results by the others
is seemingly random.  Whereas, in the current nmap, it's always the fist
target in the range that gets the result - making for a cleaner output.
It might be worth mentioning that the first coroutine locks "id" whilst
some initialising is done and then all coroutines are allowed to run and
further locking is done such that concurrent queries can be performed,
but not at the same whois service.

You shouldn't rely on any order for threads to be run against Targets.
If you would like to impose an order that is very possible by building
an ordered queue yourself for the threads.

Previously the mutex code maintained a stack for waiting threads (so
the last thread to "lock" gets the lock). Now it uses queue for
waiting threads. Again, I don't think this will solve your problem
because it sounds like you want threads run in an order (Targets)
specified via the command line.

It looks as though this order thing has been worked on since r8060, but
I can't check whether this has been successful as I'm failing to build
r8222 with the following errors:

..\nse_init.cc(17) : fatal error C1083: Cannot open include file:
'stdbool.h': No such file or directory
which was introduced in r8025 and I worked around by wrapping the
include with #ifndef WIN32 (google said stdbool.h isn't required on
windows).
LINK : fatal error LNK1104: cannot open file 'nsock.lib'

If I try building main_test I get:
..\output.cc(792) : error C2057: expected constant expression
..\output.cc(792) : error C2466: cannot allocate an array of constant size 0
..\output.cc(792) : error C2133: 'c_output' : unknown size

These build errors should be fixed.

This isn't preventing me from continuing as I'm working from r8060, but
I'd be grateful for a heads-up.

Regards,

jah

Thanks,

-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault