mailing list archives
Re: Possible bug report - nmap scan elapsed time changes into negative time
From: David Fifield <david () bamsoftware com>
Date: Sun, 27 Mar 2011 14:32:09 -0700
On Fri, Mar 25, 2011 at 09:01:47AM -0500, Daniel Miller wrote:
I looked into this some more. The particular function that affects
that output line is NmapOps::TimeSinceStartMS, which returns an int
generated with the TIMEVAL_MSEC_SUBTRACT macro #defined in
#define TIMEVAL_MSEC_SUBTRACT(a,b) ((((a).tv_sec - (b).tv_sec) * 1000)
+ ((a).tv_usec - (b).tv_usec) / 1000)
The overflow happens when the difference in seconds is multiplied by
1000. Interestingly, the TIMEVAL_SEC_SUBTRACT macro:
#define TIMEVAL_SEC_SUBTRACT(a,b) ((a).tv_sec - (b).tv_sec +
(((a).tv_usec < (b).tv_usec) ? - 1 : 0))
returns seconds, and does not suffer from this overflow. A quick grep
through the source for calls to TimeSinceStartMS:
$ find . \( -name .svn -prune -false \) -o -print0 | xargs -0 grep -H
shows that in only one case is the return value NOT divided by 1000.0
(which casts it to a float). The one case is an assignment to the
starttimems attribute of the OsScanInfo class, which is only used one
place (divided by 1000.0).
I'm attaching a patch that adds a function, NmapOps::TimeSinceStartS,
which returns a float. It does this using a new macro,
TIMEVAL_FSEC_SUBTRACT, that results in a floating-point difference in
seconds, which is the most common case. After converting all the calls
to use this function, I can no longer find any calls to
TimeSinceStartMS, but I left it in anyway. I tested this patch with a
-A -T5 -vv -dd scan of my /24 subnet, and saw no issues.
Thanks Daniel, this is a good idea. Make a few changes and I'll commit
Rename TimeSinceStartS to TimeSinceStart.
Rename starttimes to starttime.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/