Re: RFC: Nping requirements and user interface

[David Fifield <david () bamsoftware com>]

On Fri, May 22, 2009 at 12:37:14AM -0700, Fyodor wrote:
> On Sun, May 17, 2009 at 07:49:57PM +0200, Luis M. wrote:
> > PING TYPES:
> >   -pT, --tcp   : TCP ping mode.
> >   -pU, --upd   : UPD ping mode.
> >   -pI, --icmp  : ICMP ping mode.
> >   -pA, --arp   : ARP ping mode.
>
> Nmap uses a lot of these 2-character options, but I'm not sure they
> are a good Nmap trait.  It is mostly done because Nmap is so complex
> and has so many options.  Nping is a much simpler tool, so maybe we
> can get by with simpler options.  The --tcp, --upd, --icmp, and --arp
> options are well named.  You might give one-character shortcuts for
> the most common.  Like maybe -t and -u for --tcp and --udp,
> respectively.  If TCP is the default, you might not want to blow a
> single-character option on it.  You can always be sparing with the
> shortcut options now, and add more later if desired.

We're also thinking about changing to a different syntax for Nmap scan
types too. (See docs/TODO; search for "Consider rethinking Nmap's -s*
syntax".)

There can be more than one type of TCP ping, for example SYN and ACK.
What do you think about --syn and --ack options? --tcp could be a
synonym for SYN, and could fall back to connect ping for non-root users.

For shortcut options, if we decide to have them, -PU for example would
be better than -pU, for consistency with Nmap.

> We can probably deal with just the interval option.  We should
> probably have a convenience option for setting a rate (# of packets
> per second) too for people who like to specify it that way.

Maybe --rate to go with Nmap's --min-rate and --max-rate.

> >   --host-timeout <time> : Give up on target after this long.
> >   
> > MISC:
> >   -h, --help      : Display help information on stardard output.
> >   -V, --version   : Display Nping current version number. 
> >   -c, --count <n> : Stop  after  sending  (and  receiving) n response packets.
>
> What do you mean "sending (and receiving)"?  What if the target
> doesn't reply to any of the probes?  A short wait after all packets
> are sent seems reasonable though to catch any replies which do come.

I agree about having a short delay to wait for replies that haven't come
yet. Maybe what Luis meant is that if you send four probes and get back
four replies right away, there's no need to wait at all. Is that right,
Luis?

David Fifield

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