Nmap Development mailing list archives

Re: parse_timespec function


From: Fyodor <fyodor () insecure org>
Date: Wed, 7 Apr 2010 00:30:13 -0700

On Mon, Apr 05, 2010 at 02:02:18PM -0600, David Fifield wrote:

Here's a proposed function to go in stdnse.

---
-- Parses a time duration specification, which is a number followed by a
-- unit, and returns a number of seconds. The unit is optional and
-- defaults to seconds. The possible units (case-insensitive) are
-- * <code>s</code>: seconds,
-- * <code>m</code>: minutes,
-- * <code>h</code>: hours.
-- In case of a parsing error, the function returns <code>nil</code>
-- followed by an error message.

Defaulting to seconds does sound like the right way to go, but it is
worth noting that Nmap's other time value options all take
milliseconds:

  Options which take <time> are in milliseconds, unless you append 's'
  (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
  --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies
      probe round trip time.
  --host-timeout <time>: Give up on target after this long
  --scan-delay/--max-scan-delay <time>: Adjust delay between probes

It would be nice if Nmap's time options were consistent in this
respect, though I'm not sure we will be able to achieve that.  Seconds
does sound reasonable for NSE, but changing the default unit of these
five existing options would be ugly from a compatibility/documentation
standpoint.  Still, --host-timeout would benefit from defaulting to
seconds, I think.  And the other four would be fine with seconds as
long as you could specify float values like 0.75.

I'm starting to think maybe we should bite the bullet and make all of
these options take seconds by default, and allow floating point
values.  What do others think?

Also, don't you think we should allow floating point values for the
NSE arguments too?  I'm sure some scripts will want values of less
than a second, or partial values such as 1.5.

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


Current thread: