mailing list archives
Re: RFC: Nping requirements and user interface
From: David Fifield <david () bamsoftware com>
Date: Sun, 24 May 2009 16:59:02 -0600
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:
-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*
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.
-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,
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org