Re: [NSE] qscan first read timeout value too short?

[David Fifield <david () bamsoftware com>]

On Fri, Aug 20, 2010 at 10:11:13PM +0100, jah wrote:
>  On 19/08/2010 15:27, Luis MartinGarcia. wrote:
> > On 08/07/2010 12:52 AM, David Fifield wrote:
> > > Do you think it's related to this recent message?
> > >
> > > Nsock has trouble handling pcap reads on Windows
> > > http://seclists.org/nmap-dev/2010/q3/232
> > >
> > > Luis found that pcap reads on Windows were not being polled often
> > > enough.  His patch was applied in r19487, so you should have the fix
> > > already. Luis, you mentioned to me that you confirmed the bug existed
> > > with NSE also. Can you reproduce this behavior with qscan?
> >
> > Sorry for my late reply. I didn't read your message until now.
> >
> > I did confirm that the bug also affected NSE but I had to cheat a bit in
> > order to obtain clear results. A quick explanation is at the end of this
> > email [1].
> >
> > About Qscan, I can't try to reproduce it right now, but I don't think is
> > related. The bug I traced did not cause packet loss, it just caused a
> > delay on its detection. This is a long shot but I think what we are
> > dealing with here is that the script sends a probe, but pcap is not
> > ready by the time we receive the first reply.
> >
> > Also, after a very quick look to the script I see that qscan.nse
> > performs certain operations in a different order than ipidseq.nse.  Jah,
> > would you try the patch I attach? Sorry if the patch looks absurd, but
> > my experience with NSE is close to zero.
>
> You are correct about the lost response being unrelated to your changes, I've reproduced this issue on builds from 
> revisions prior to yours (which was r19487).
> I've tried your patch (which moves the call to pcap_register after sending the probe). It made no difference to the 
> result as you can see from the output below. It did however throw-up something potentially interesting (which I 
> haven't looked into yet).

I've been looking into this. I can reproduce it on Windows XP. What I've
found so far is that l_nsock_ncap_register always starts a read event as
soon as you call nmap.pcap_register--whether you've done an
nmap.pcap_receive yet or not.

int l_nsock_ncap_register(lua_State * L)
{
        ...
        /* always create new event. */
        nr->nseid = nsock_pcap_read_packet(nsp,
                udata->nsiod, l_nsock_pcap_receive_handler, udata->timeout, nr);
        ...
}

Thus it's very possible for this read event to time out before a probe
is even sent. Naturally this isn't how anyone expects it to work, and it
seems to work fine on Linux. Maybe there is some special conditional
Windows code at work. I'll look into it more.

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