Re: [nmap-svn] r28292 - in nmap: . nsock/src

[David Fifield <david () bamsoftware com>]

On Thu, Mar 22, 2012 at 02:51:26PM -0700, Fyodor wrote:
> On Fri, Mar 16, 2012 at 01:02:57PM -0700, commit-mailer () insecure org wrote:
> > Log:
> > Update nsock_tod before creating a timer.
> >
> > nsock_tod is Nsock's idea of the current time. It is updated when an
> > nsock_pool is initialized, on each iteration of nsock_loop, and in a few
> > other places. What could go wrong, with respect to timers, is a sequence
> > like this:
> >     nsp_new
> >     [... some long delay ...]
> >     nsock_create_timer(timeout)
> >     nsock_loop
> > The time elapsed after the creatino of the timer until it fires would
> > not be timeout, but rather timeout - delay. If the delay was long
> > enough, the timer would fire as loop as nsock_loop was entered.
> >
> > This showed itself in IPv6 OS detection. We schedule 6 timers
> > immediately, 100 ms apart. If the pcap_open or anything else took too
> > long, then the timers would fire all at once. This messed up the
> > calculation of the TCP_ISR feature.
> >
> > Perhaps we should do this when any new event is created? It is already
> > done manually at the beginning of each of the connect functions.
>
> Adding this to event creation sounds good to me.

I've done this now. It turns out I had earlier debugged almost exactly
the same problem in r19970, and mentioned the same fix.

David Fifield

r19970 | david | 2010-08-25 19:56:51 -0700 (Wed, 25 Aug 2010) | 26 lines

Do a gettimeofday to refresh nsock_tod at the top of nsock_pcap_open.

jah found that the first pcap read was always timing out in qscan.nse.
http://seclists.org/nmap-dev/2010/q3/542. According to the logs, the
read event was happening around a second before the script's first probe
was sent, even though the script does things in the opposite order. The
read event was already long timed out by the time the probe was sent.
This only happened to the first read.

What was happening was that nsock_tod, Nsock's cache of the
gettimeofday, was stale. It still had the value it was initialized with
when nsp_new (via open_nse) was called, even before port scanning was
done. nsock_tod is updated frequently in nsock_loop but not outside it.
The first read event was scheduled before nsock_loop was entered, so it
had the seconds-old timeout, but subsequent reads were fine.

I think we really should be updating nsock_tod when every event is
added. But I didn't find a good centralized place to do it;
nsp_add_event already gets an absolute timeout. So I took a cue from the
connect functions. Outside of nsock_loop, nsock_tod is only updated in
nsock_connect_*. I think the logic here is that you might wait a while
before starting a connection, but then subsequent events on the same iod
will come quickly. The same thing happens with nsock_pcap_open; once you
open it it's likely that you will start new events soon, so it's a good
place to update.
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/