Re: parse_timespec function

[Fyodor <fyodor () insecure org>]

On Thu, Apr 08, 2010 at 11:13:21AM -0600, David Fifield wrote:
> I thought about that too and I meant to mention it. I was concerned
> about consistency with existing scripts and libraries but it turns out
> there wasn't much to be consistent with. This is what I can find:
>
> dns-fuzz   dns-fuzz.timelimit seconds
> nmap       set_timeout        milliseconds (not normally accessible to user)
> mssql      mssql.timeout      seconds
> smb-psexec timeout            seconds
> qscan      qscan.delay        milliseconds
> unpwdb     unpwdb.timelimit   seconds
>
> Floating-point values are fine, as is adding "ms" for a multiplier of
> 0.001.

That sounds great for the NSE stuff.  I tend to think we should not
require a leading zero, so .5 or .005 can be used instead of 0.5 or
0.005.

> Changing the default to seconds for Nmap options is a good design
> but it will likely have a high cost in terms of breaking people's
> scripts.

I agree.  So for these:

  --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

How does this sound?

o Change our parser to allow ms and float, like you're doing for NSE

o Change the default for bare times to be seconds, as with NSE

o If we see a bare time value which looks 1,000 times too high, print
  a prominent warning message, as they probably meant for their result
  to be in milliseconds.  Of course the warning would note the change.
  Even a fatal error would probably be OK, since if someone really
  wants the iffy value, they can just specify it with 's' (or
  whatever) at the end. As for the boundaries, maybe we could give the
  warning if an unqualified time is given and it is:

  o >= 50 for --min-rtt-timeout, --max-rtt-timeout, or
    --initial-rtt-timeout (you'd normally not wait more than 50s for a
    packet response).
  o >= 10000 for --host-timeout (you'd normally not specify a 2.7+
    hour timeout for individual hosts).
  o >= 100 for --scan-delay/--max-scan-delay (you'd normally not ask
    Nmap to wait 100 seconds or more between probes, nor would you ask
    Nmap to cap the delay limit that high).

  I realize there are edge cases where you might want to specify values
  this high in seconds, but in that case you can just add the "s"
  qualifier to show that you really mean it, or you can just ignore the
  warning (if it is just a warning and not an error).

o Go over the man page and every instance in the book where any of
  these options are used to ensure they are used properly.  If we use
  qualifiers ("50s") in the book and man page examples, they'll still
  work when plugged into previous versions of Nmap.

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