Re: parse_timespec function

[David Fifield <david () bamsoftware com>]

On Thu, Apr 08, 2010 at 02:41:06PM -0700, Fyodor wrote:
> 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 have done this. All the options affected are
  Nmap:
    --host-timeout
    --max-rtt-timeout --min-rtt-timeout --initial-rtt-timeout
    --scan-delay --max-scan-delay
    --stats-every
  Ncat:
    -d --delay
    -i --idle-timeout
    -w --wait
  Nping:
    --delay
    --host-timeout
    --icmp-orig-time --icmp-recv-time --icmp-trans-time
I added in the sanity checks you suggested. For example,

$ ./nmap --host-timeout 10000
The default unit for --host-timeout is seconds (since April 2010), so your time of "10000" is 2.8 hours. If this is 
what you want, use "10000s".
QUITTING!

$ ./nmap --max-rtt-timeout 60
The default unit for --max-rtt-timeout is seconds (since April 2010), so your time of "60" is 60 seconds. Use "60ms" 
for 60 milliseconds.
QUITTING!

$ ./ncat -d 100
Ncat: The default unit for -d is seconds (since April 2010), so your time of "100" is 1.7 minutes. Use "100ms" for 100 
milliseconds. QUITTING.

$ ./nping --delay 15
The default unit for --delay is seconds (since April 2010), so your time of "15" is 15 seconds. Use "15ms" for 15 
milliseconds.

Using a unit always disables the errors. I used my judgement for the
Ncat and Nping options.

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

I did this too. It turns out that tval2msecs already supported the "ms"
suffix, it just wasn't documented. So when I had a choice, I changed
bare numbers to have the "ms" suffix (as opposed to converting to a
decimal) so that it's compatible with previous versions.

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