Home page logo
/

nmap-dev logo Nmap Development mailing list archives

nping notes
From: dan farmer <zenfish () gmail com>
Date: Sat, 14 Apr 2012 21:36:09 -0700

Not sure how readable the below will be, based on formatting
restrictions/etc of list, stripping, etc... So I'm attaching a doc file,
which can also be read at:


http://trouble.org/nping.docx


Tried hard to make this coherent, I blame fyodor bullying me into sending
this out.. Just got back from a trip, I'm tired, etc., etc.


It might seem like some pretty harsh critique, but it is only meant in most
constructive of ways.  I only wrote so much 'cuz I like the idea.


-- d


nping notes
 
(A few notes on nping¹s behavior and output.   Fyodor coerced me into send
to the list, so blame him if you don¹t like it ;))
 
I just noticed nping the other day, and it was a pleasant surprise.  After
using it, however, I wasn¹t really sure what nping was supposed to do.  I
guess quite a bit of what I¹m putting down was based on some preconceptions
I had, but as I learned more about the tool I perhaps became even more
entrenched in my views (chalk it up to my personality.)  I don¹t write all
this up as a general gripe fest against the tool; it¹s interesting enough to
at least register some hopefully constructive & coherent critique.
 
I¹ll present my biases up front: simple is better, easy to understand is
better, and clear is better.
 
³You² is directed at the code writers ;)
 
Most was based on 5.51 build, but I tried to retest on 5.61 which seems to
be the latest, apologies for any errors, etc., etc., blah blah blah.
 
Basic summary
 
Cool tool, lots of neat features, wish it were split up into pieces and
produced more coherent and usable output.
 
I¹m not sure what gap it was supposed to fillŠ but feature overload hurt
this tool much more than nmap¹s feature overflow.

Big 4 complaints
 
1)    There are multiple ways of doing the same thing; for instance the 3
ways of talking about negative verbosity that are all equal:  -1, a1, and
q1.  Among other things this breeds confusion and pointlessly complicates
the already bewildering amount of options.    Having various, sundry,
repetitive, and unpredictable (at least by me!) modalities in input, output,
and behavior harm the tool.  With so many options (80+?), and several have
multiple or complex options in them, some being apparently the same (but I'm
not even sure on that), and with the shifting modalities based on euid
and/or priv's ­ this is even more confusing to the user and just plain wrong
at other times - that it pretty much guarantees that there are numerous bugs
because of their complexity and how they're handled.  (I've already found a
few in just casual testing, wondering what the heck they do.)  In addition,
even if you could get them bug free their wording is imprecise.   For
instance you say root sometimes, administrative privs in other spots, raw
packet privs in others.  If you use something multiple times in docs just
define it once at the top and stick with it.

 

Sometimes options are ignored (try "nping -c 1 -v4  -p 80 --mf  192.168.0.1"
- note the no --tcp option, then try again with the --tcp option), sometimes
they generate errors, sometimes based on the user you are as well.  You have
to be consistent (well of course you don't have to, but it would be nice ;))

 
I won't argue about all the functionality crammed into the tool, but I'd
lobby at least to remove all bajillion redundant options and aim for a
cleaner user experience.  Kill off each and all redundant option.  And every
option doesn't have to have an equal and opposing option.   For instance the
output section in the man page has 8 entries that could be replaced with 1,
maybe 2 options (3 different ways of talking about negative verbosity that
are all equal?  -1, a1, and q1 are all the same?  Come on, that's just
silly!):
 
-v          : Increment verbosity level by one.
-v[level]   : Set verbosity level. E.g: -v4
-d          : Increment debugging level by one.
-d[level]   : Set debugging level. E.g: -d3
-q          : Decrease verbosity level by one.
-q[N]       : Decrease verbosity level N times
--quiet     : Set verbosity and debug level to minimum.
--debug     : Set verbosity and debug to the max level.
 
How about just one:
 
-v[level]   : Set verbosity level; ranges from -4 to +4, with higher
values printing more details.  E.g: -v4.
 
And, I hate to say itŠ with so many optionsŠ why are some left out? I¹m the
last to argue for more complexity, but why have two different --badsum
options (set random invalid checksum) and no option to set the checksum to
what I want it to be?   Two flags for IP fragmentation bits and not a
fragmentation offset option?  Etc. Have options for all the IP fields (more
on this in suggestions.)
 
2)    Different and almost invisible but important behavior based on
intangibles is a really, really bad idea.  Yes, Nmap does this too, and I¹ve
already griped to Fyodor about it long ago (see what good it did there!)
But to have nping do one thing when you¹re root and a very different thing
as a normal user in the most common option of them all is guaranteed to
confound and garner negativity.  I¹m talking about the simple:

 
$ nping example.com
 
Vs. the very different:
 
# nping example.com
 
The difference here, if not clear, is the prompt; the euid of the user,
whether priv¹d or not (actually I think sometimes it¹s euid, and othertimes
permissions on the dev).  I¹ll talk about this more later.  But suffice it
to say that invisibly toggling behavior and changing output based on euid
(or w/e is used) is not a very friendly thing to do, and certainly against
the unix tradition (shaking my cane!)  I had no idea why it was doing tcp
pings by default Š then found out as root it did icmp by default.  I'd much
rather get an error as an upriv'd user.  FWIW, IMHO, etc. (FWIW/FYI, on some
linux systems, you can do ³# cp /bin/ping /tmp/tmp-ping; setcap
'cap_net_raw=+ep' /tmp/tmp-ping² and /tmp/tmp-ping will work like normal
ping, even w/o SUID bit.)


Confusion was to be had when I got nping positive response and then a second
later it didn¹t until I figured that the uid¹s were different, blah.
3)    I¹ll be writing fairly extensively about the output, but it¹s a real
mess. Usability-wise this is the hardest one to take.  The attempted of
melding of very different tools (e.g. ping, traceroute and others) into a
single output format often doesn¹t work, and it suffers in comparison to the
tools that it emulates.   As it stands I¹m not sure why I¹d use sping in
such cases unless I was just tired of the old ones or had something very
special to test.

 
4)    At least at the start I really didn¹t know what the hell the tool
really is.   In a small bit I¹ll quote from private email, I was told that
³I'd like to start by saying that Nping was never intended to mimic other
ping tools.²   This floored me a bit. If I write a new way of interacting
with man pages and call it Nman you might be expected to get some critique
and/or puzzled users when it doesn¹t act like man.   Why not npacket or
something completely different (nfyodor?)  I think after beating on it a bit
I understand, but again, this is just something almost intentionally
designed to confuse users.

 
Output
 
O1) The granularity of verbosities (e.g. ­v/-d flags) is a bit broken.
Bottom line ­ there¹s no reasonable way of telling which hosts answer when
pinging hosts (which, unless I¹m not mistaken, is kind of the point of this
toolŠ?)
 
For instance, I have a choice between the default flood, which is 4-8 lines
per host ((send + possible receive) * 4) + a fair bit of summary data:
 
      # nping 192.168.0.0/24
Starting Nping 0.5.51 ( http://nmap.org/nping ) at 2012-04-14 21:00 PDT
SENT (0.0265s) ICMP 192.168.0.55 > 192.168.0.0 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0266s) ICMP 192.168.0.55 > 192.168.0.1 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0266s) ICMP 192.168.0.55 > 192.168.0.2 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0267s) ICMP 192.168.0.55 > 192.168.0.3 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0267s) ICMP 192.168.0.55 > 192.168.0.4 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0268s) ICMP 192.168.0.55 > 192.168.0.5 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0268s) ICMP 192.168.0.55 > 192.168.0.6 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0268s) ICMP 192.168.0.55 > 192.168.0.7 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0269s) ICMP 192.168.0.55 > 192.168.0.8 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0269s) ICMP 192.168.0.55 > 192.168.0.9 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0269s) ICMP 192.168.0.55 > 192.168.0.10 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0270s) ICMP 192.168.0.55 > 192.168.0.11 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0270s) ICMP 192.168.0.55 > 192.168.0.12 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0270s) ICMP 192.168.0.55 > 192.168.0.13 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
SENT (0.0271s) ICMP 192.168.0.55 > 192.168.0.14 Echo request (type=8/code=0)
ttl=64 id=47447 iplen=28
RCVD (0.0272s) ICMP 192.168.0.6 > 192.168.0.55 Echo reply (type=0/code=0)
ttl=64 id=25233 iplen=28
[Š tons of output elided Š]
Statistics for host 192.168.0.0:
 | Probes Sent: 1 | Rcvd: 0 | Lost: 1 (100.00%)
 |_ Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Statistics for host 192.168.0.1:
 | Probes Sent: 1 | Rcvd: 1 | Lost: 0 (0.00%)
 |_ Max rtt: 0.859ms | Min rtt: 0.859ms | Avg rtt: 0.859ms
Statistics for host 192.168.0.2:
 | Probes Sent: 1 | Rcvd: 0 | Lost: 1 (100.00%)
 |_ Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
[Š more output elided Š]
 
This gives a wall of data that is essentially and ­ most frustratingly ­
doesn¹t tell me what I really want to know (who answered or didn¹t answer
pings).  So I could try to write a script to parse the replies, but the
multiline summary lines makes it impossible to use grep without some
gyrations.  Nmap does a pretty good job with default output and even throws
in some layer 2 magic if you¹re on the same subnet, a nice bonus.
 
If I think that cranking the output down to the next level might help I¹d be
wrong, because there¹s absolutely no answers at all then:
 
      # nping ­q 192.168.0.0/24
Starting Nping 0.5.51 ( http://nmap.org/nping <http://nmap.org/nping>  ) at
2012-02-11 23:23 PST
Raw packets sent: 255 (7.140KB) | Rcvd: 8 (368B) | Lost: 247 (96.86%)
Tx time: 0.76803s | Tx bytes/s: 9296.54 | Tx pkts/s: 332.02
Rx time: 1.76927s | Rx bytes/s: 208.00 | Rx pkts/s: 4.52
Nping done: 255 IP addresses pinged in 1.80 seconds
 
Only prints summary data and doesn¹t tell me who answered. Throw me a ICMP
bone here.  Nmap pinging (e.g. -sn) is more in line with what I'd expect.
In particular you have to put in a summary line that includes success rate ­
e.g., what the slower, plodding nmap does:
 
      Nmap done: 255 IP addresses (8 hosts up) scanned in 4.82 seconds
 
In nping's case you might want a similar summary line on a per-proto basis.
 
O2) Traceroute optionsŠ ok, traceroute to google (small font in an effort to
make it readable):
 
# ./nping -c 15 --traceroute google.com
 
Starting Nping 0.5.61TEST5 ( http://nmap.org/nping ) at 2012-04-14 19:51 PDT
SENT (0.0177s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=1 id=62769 iplen=28
RCVD (0.0183s) ICMP 192.168.0.1 > 192.168.0.55 TTL=0 during transit
(type=11/code=0) ttl=255 id=7570 iplen=56
SENT (1.0202s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=2 id=62769 iplen=28
RCVD (1.0380s) ICMP 63.231.10.129 > 192.168.0.55 TTL=0 during transit
(type=11/code=0) ttl=254 id=62769 iplen=56
SENT (2.0203s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=3 id=62769 iplen=28
RCVD (2.0373s) ICMP 71.217.185.249 > 192.168.0.55 TTL=0 during transit
(type=11/code=0) ttl=252 id=0 iplen=56
SENT (3.0213s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=4 id=62769 iplen=28
RCVD (3.0495s) ICMP 67.14.41.26 > 192.168.0.55 TTL=0 during transit
(type=11/code=0) ttl=249 id=0 iplen=56
SENT (4.0213s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=5 id=62769 iplen=28
RCVD (4.0396s) ICMP 65.122.121.66 > 192.168.0.55 TTL=0 during transit
(type=11/code=0) ttl=249 id=0 iplen=56
SENT (5.0214s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=6 id=62769 iplen=28
RCVD (5.0400s) ICMP 66.249.94.214 > 192.168.0.55 TTL=0 during transit
(type=11/code=0) ttl=249 id=0 iplen=56
SENT (6.0214s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=7 id=62769 iplen=28
RCVD (6.0401s) ICMP 66.249.94.197 > 192.168.0.55 TTL=0 during transit
(type=11/code=0) ttl=249 id=54628 iplen=168
SENT (7.0215s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=8 id=62769 iplen=28
SENT (8.0215s) ICMP 192.168.0.55 > 74.125.224.70 Echo request
(type=8/code=0) ttl=9 id=62769 iplen=28
RCVD (8.0599s) ICMP 216.239.47.185 > 192.168.0.55 TTL=0 during transit
(type=11/code=0) ttl=248 id=25340 iplen=168
 
First - why on earth would you output the destination IP rather than the hop
that it dies on?   You just lost the point of traceroute, and none of the
options seems to give me what I want (hops and times.)  Honestly I don't
even know what this option is supposed to do, or what its designed for.
You seem to send a set of 32 packets no matter what I point it at (e.g.
Google or my router, one hop away.)
 
But you also miss the other fundamental tracerouty feature ­ the time on
each hop.  I'll talk more about this in #XXX below, but the times you
specify are completely human unreadable.   And when doing --traceroute what
does the overall RTT stand for?  For all hops smushed together?  For the
endpoint only?   For both ICMP and TCP/whatever if I specify multiple
protocols?   For that matterŠ rtt/raw packets/tx/rx lines ­ perhaps have one
of each of those per proto?   Or even per proto per target, as the verbosity
increases.   Smashing 2 host's stats together when they're on different nets
typically doesn't make a whole lot of sense.
 
Traceroute¹s output is a wonderful little bit of summation ­ also note how
when it gets to the 10th hop it loses no readability, while yours jostles
the output over by one (more on this in a bit):
 
# traceroute to google.com (74.125.224.72), 30 hops max, 60 byte packets
 1 192.168.0.1  0.809 ms  1.121 ms 1.420 ms
 2 63.231.10.129  19.397 ms  21.458 ms 22.693 ms
 3 71.217.185.249  23.965 ms  25.425 ms 26.667 ms
 4 67.14.41.26  28.429 ms  29.691 ms 59.695 ms
 5 65.122.121.66  32.264 ms  33.776 ms 35.438 ms
 6 66.249.94.212  36.675 ms 66.249.94.214  37.540 ms  39.105 ms
 7 66.249.94.199  40.253 ms 66.249.94.197  23.877 ms 66.249.94.199  23.362
ms
 8 209.85.240.228  27.182 ms * *
 9 216.239.49.199  48.873 ms 216.239.47.185  44.069 ms 216.239.49.199
46.127 ms
10  209.85.250.61 43.263 ms  43.242 ms  43.423 ms
11  64.233.174.19 42.856 ms  43.654 ms  42.543 ms
12  74.125.224.69 42.843 ms  41.908 ms  42.366 ms
 
Nmap again deals with this reasonably as well.
 
O3) Basic pingingŠ when you ping something it returns Š something.   But
it's not that useful unless you're quick with the arithmetic ­ come on, even
DOS tells you how long the ping took!   You have tons of info in the lines,
but the most useful two ­ the host answering and how long it took to respond
­ are buried.   Take a 50,000 foot look at the two outputs:
 
./nping 192.168.0.1
 
Starting Nping 0.5.61TEST5 ( http://nmap.org/nping ) at 2012-04-14 20:06 PDT
SENT (0.0189s) ICMP 192.168.0.55 > 192.168.0.1 Echo request (type=8/code=0)
ttl=64 id=4882 iplen=28
RCVD (0.0198s) ICMP 192.168.0.1 > 192.168.0.55 Echo reply (type=0/code=0)
ttl=255 id=7584 iplen=28
SENT (1.0205s) ICMP 192.168.0.55 > 192.168.0.1 Echo request (type=8/code=0)
ttl=64 id=4882 iplen=28
RCVD (1.0212s) ICMP 192.168.0.1 > 192.168.0.55 Echo reply (type=0/code=0)
ttl=255 id=7585 iplen=28
SENT (2.0206s) ICMP 192.168.0.55 > 192.168.0.1 Echo request (type=8/code=0)
ttl=64 id=4882 iplen=28
RCVD (2.0212s) ICMP 192.168.0.1 > 192.168.0.55 Echo reply (type=0/code=0)
ttl=255 id=7586 iplen=28
SENT (3.0206s) ICMP 192.168.0.55 > 192.168.0.1 Echo request (type=8/code=0)
ttl=64 id=4882 iplen=28
RCVD (3.0212s) ICMP 192.168.0.1 > 192.168.0.55 Echo reply (type=0/code=0)
ttl=255 id=7587 iplen=28
SENT (4.0207s) ICMP 192.168.0.55 > 192.168.0.1 Echo request (type=8/code=0)
ttl=64 id=4882 iplen=28
RCVD (4.0213s) ICMP 192.168.0.1 > 192.168.0.55 Echo reply (type=0/code=0)
ttl=255 id=7588 iplen=28
nping_event_handler(): TIMER killed: Resource temporarily unavailable
 
Max rtt: 0.788ms | Min rtt: 0.578ms | Avg rtt: 0.635ms
Raw packets sent: 5 (140B) | Rcvd: 5 (230B) | Lost: 0 (0.00%)
Tx time: 4.00184s | Tx bytes/s: 34.98 | Tx pkts/s: 1.25
Rx time: 5.00161s | Rx bytes/s: 45.99 | Rx pkts/s: 1.00
Nping done: 1 IP address pinged in 5.04 seconds

Vs.
 
[root () blackhol3 nping]# ping -c 4 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.611 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.619 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.629 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=255 time=0.608 ms
 
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.608/0.616/0.629/0.031 ms
 
The first is only readable on a line-by-line basis, while the 2nd is clear
and understandable on individual lines as well as overall.  You see where
the jumps in times are (if any), you see what hop you¹re on, etc., etc.
 
O4) Jitter.   Back to nping outputŠ just some ideas to try to remove all the
jitter between lines to make them readable, nothing fancy.
 
SENT (0.0015s) ICMP 192.168.0.199 > 192.168.0.1 Echo request (type=8/code=0)
ttl=64 id=10390 iplen=28
RCVD (0.0021s) ICMP 192.168.0.1 > 192.168.0.199 Echo reply (type=0/code=0)
ttl=255 id=54692 iplen=28
...
SENT (9.0078s) ICMP 192.168.0.199 > 192.168.0.1 Echo request (type=8/code=0)
ttl=64 id=16397 iplen=28
RCVD (9.0085s) ICMP 192.168.0.1 > 192.168.0.199 Echo reply (type=0/code=0)
ttl=255 id=54732 iplen=28
SENT (10.0086s) ICMP 192.168.0.199 > 192.168.0.1 Echo request
(type=8/code=0) ttl=64 id=16397 iplen=28
RCVD (10.0093s) ICMP 192.168.0.1 > 192.168.0.199 Echo reply (type=0/code=0)
ttl=255 id=54733 iplen=28
 
Jitter ­ changing field location and length between lines ­ is a real
problem with your ping when visually inspecting it ­ hosts (esp. with very
different hostname lengths, like FQDNs) and IP #'s that have different
lengths, multiple hosts being pinged (forget it), climbing time (because the
seconds vary a fair bit (at least early on) you shift everything to the
right 1 at 10, and again at 100) and the request/reply differences just kill
the output.  As a result things like the traceroute mode are absolutely
useless with your tool ­ the big thing there is what are the hops, you don¹t
see that at all.   But also ­ what are the hops and timesŠ with normal
traceroute I can see at hop 7 I have an issue, since the time jumps to 10x
the previousŠ. (Or does the "* * *" thing ­ what would that look like, if
anything, in nping?)
 
Here¹s something I personally find more readable.  Killing off superfluous
bits, putting the important things in front/back, etc.
 
# sping --traceroute 192.168.100.1
 1 SENT ICMP 10.0.0.1 > 192.168.100.1 type=8/0 len=28 ttl=64  id=1039   16
ms
         ICMP 10.0.0.1 < 10.0.1.1      type=0/0 len=28 ttl=255 id=5469   22
ms
 2 SENT ICMP 10.0.0.1 > 192.168.100.1 type=8/0 len=28 ttl=64  id=1039   16
ms
         ICMP 10.0.0.1 < 192.168.0.1   type=0/0 len=28 ttl=255 id=5469  622
ms
 3 SENT ICMP 10.0.0.1 > 192.168.100.1 type=8/0 len=28 ttl=64  id=1039 1016
ms
         ICMP 10.0.0.1 < 192.168.0.1   type=0/0 len=28 ttl=255 id=5469 1022
ms
 
I kept the host identifiers on the same side rather than shuffling them back
and forth and toggle the "<" and ³>² back and forth to indicate direction.
 
A more radical transformation would to make it more like traceroute and kill
the outbound traffic (perhaps put back in with ­v flags), but now it¹s
looking more and more like the old traceroute:
 
 1   12.0 ms ICMP    10.0.1.1 type=0/0 len=28 ttl=255 id=5469   22 ms
 2  666.0 ms ICMP 192.168.0.1 type=0/0 len=28 ttl=255 id=5469  622 ms
 3  975.0 ms ICMP 192.168.0.1 type=0/0 len=28 ttl=255 id=5469 1022 ms
 
 
And Š. Use milliseconds, please.   Virtually everyone else does.  Or less,
if you have great clocks on the system.  But you're making the user work.
10ms is infinitely easier to read than 0.001s.   A real pain point here is
that, unlike normal ping, if I do 20 or 50 packets it's entirely not obvious
what packets had a hard time.   With your tool it's a wall of numbers ­ with
ping the differences are really easy to spot.   AndŠ was it a contest to use
as many different separators as possible or something? :)
 
(BTW, you use iplen in the man page output and don¹t define it.)
 
Miscellaneous
 
M1) --traceroute is a bit odd as implemented.  In theory, sure, traceroute
to target and do the sping thing to the target.  In theory.  Try to
anticipate what it does in combination with/without the ­c flag is
challenging:
 
      # nping ­c 1 --traceroute google.com            (case #1)
 
      # nping      --traceroute google.com            (case #2)
 
So in the firstŠ it sends a packet, dies at first hop, which is sort of
reasonable.  The second caseŠ first of all, it sends 1 packet per hop.  Why
one?  Sping generally seems to default at 4 packets, and the real traceroute
defaults to the familiar 3.  But then, when it reaches its target, it falls
back to ping mode, and just starts tossing out ICMPs forever more.   Don¹t
mix modes ­ stop after you reach the target?
 
Also, adding the ­p port option to first example does nothing ­ I guess the
­p is only for the target system. I¹d prefer having options to use on each
set of the hop rather than the end point.   Doing something like ³nping ­c 1
­p 80 google.com² could send a packet to port 80 on each hop, which would be
nifty, if a bit odd. Seems more intuitive than ICMP until the end (if it
ever hits) and then do something completely different.
 
It currently uses the ICMP experimental traceroute (kind of amusing for the
man page to call RFC 1393, written 20 years ago, as experimental, but I
guess it is); you might also mention that the current default behavior
duplicates the ­I option in modern traceroutes.  And you really should have
a non-ICPMP option.
 
HmmŠ that and the number of packets per hopŠ you could collapse the 3
existing and identical traceroute options into one, with an optional arg to
use the other kind?   (E.g. --traceroute=N[i], where you could say
--traceroute or --traceroute=1, or --traceroute=3i, for 3 packets per hop
and use ICMP.  Or something.  Something that is predictable.
 
M2) Delay default is wacked.  The man says:
 
--delay time (Delay between probes).  This option lets you control for how
long will Nping wait before sending the next probe. Like in many other ping
tools, the default delay is one second.
 
Yes, ping defaults to 1 second delay ­ but it can only ping a single host!
When I did an sping on a /24 I thought something was broken ­ surely you
can¹t think that the expected ping time of a /24 is over 15mins!  With N
targets you're multiplying the time by N.  As a user I expect the tool to
work the same in the same amount of time ­ 2 pings or traceroutes should not
take twice as long than a single one.   Nmap takes a few seconds to scan a
/24 ­ do you really think that users would expect nping to take 72 hours to
ping a /B with the default options?
 
It¹s especially silly because nmap (which blazes through a subnet) is
actually a fair bit slower pinging than nping (maybe 50% turbo speed boost?)
with delay set to 0.  I suspect Fyodor is sabotaging the code ;)
 
Perhaps 1s delay per host is more reasonable as a default, so the first set
of hosts will answer, then pause, the blast, then pause, etc.   If you¹re
afraid someone will do ³sping 10/8² or whatever, put some limit on the
number that can be overridden (I never quite know what what nmap does, but
it doesn¹t hassle me with such minutia, and just works.)  But with multiple
hosts the 1s delay is broken.
 
M3) The ping packet size was changedŠ among other things it can tip off
someone you¹re using nping vs. system ping. Change is interesting, perhaps a
line in the dox?  (As for me, "if it was good enough for Mike Muus it's good
enough for me!")   Tcpump of two pings, first nping, 2nd /bin/ping (both
ping & response):
 
17:57:07.881229 IP blackhol3.com > 192.168.0.6: ICMP echo request, id 41754,
seq 1, length 8
      0x0000: c82a 140b 0bbd 0025 9064 2b82 0800 4500 .*.....%.d+...E.
      0x0010: 001c 5dea 0000 4001 9b69 c0a8 0037 c0a8 ..]... ()   i   7  
      0x0020: 0006 0800 54e4 a31a 0001 0000 0000 0000 ....T...........
      0x0030: 0000 0000 0000 0000 0000 0000           ............
17:57:07.881315 IP 192.168.0.6 > blackhol3.com: ICMP echo reply, id 41754,
seq 1, length 8
      0x0000: 0025 9064 2b82 c82a 140b 0bbd 0800 4500 .%.d+..*......E.
      0x0010: 001c 7490 0000 4001 0000 c0a8 0006 c0a8 ..t... ()          
      0x0020: 0037 0000 5ce4 a31a 0001                 .7..\.....
 
 
17:57:10.101623 IP blackhol3.com > 192.168.0.6: ICMP echo request, id 62030,
seq 1, length 64
      0x0000: c82a 140b 0bbd 0025 9064 2b82 0800 4500 .*.....%.d+...E.
      0x0010: 0054 0000 4000 4001 b91b c0a8 0037 c0a8 .T.. ()  @......7..
      0x0020: 0006 0800 8765 f24e 0001 d41e 8a4f 0000 .....e.N.....O..
      0x0030: 0000 5609 0b00 0000 0000 1011 1213 1415 ..V.............
      0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
      0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
      0x0060: 3637                                    67
17:57:10.101669 IP 192.168.0.6 > blackhol3.com: ICMP echo reply, id 62030,
seq 1, length 64
      0x0000: 0025 9064 2b82 c82a 140b 0bbd 0800 4500 .%.d+..*......E.
      0x0010: 0054 a5e9 4000 4001 0000 c0a8 0006 c0a8 .T.. ()  @.........
      0x0020: 0037 0000 8f65 f24e 0001 d41e 8a4f 0000 .7...e.N.....O..
      0x0030: 0000 5609 0b00 0000 0000 1011 1213 1415 ..V.............
      0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
      0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
      0x0060: 3637                                    67
 
 
The difference between normal and ­1 seems too much, as well, at least for
some probes.  Say ping, that's the most basic.  I have two options ­ write a
program to summarize all the data that pour out in the default, or use nmap
to do it instead.  -q doesn't even tell me how many hosts responded, let
alone who they are!
 
# nping -q -c 1 --rate 255  192.168.0.1-255
 
Starting Nping 0.5.51 ( http://nmap.org/nping <http://nmap.org/nping>  ) at
2012-02-11 23:23 PST
Raw packets sent: 255 (7.140KB) | Rcvd: 8 (368B) | Lost: 247 (96.86%)
Tx time: 0.76803s | Tx bytes/s: 9296.54 | Tx pkts/s: 332.02
Rx time: 1.76927s | Rx bytes/s: 208.00 | Rx pkts/s: 4.52
Nping done: 255 IP addresses pinged in 1.80 seconds
 
Nmap pinging (e.g. -sn) is more in line with what I'd expect.  In particular
you have to put in a summary line that includes success rate ­ e.g., what
the slow, plodding nmap does:
 
      Nmap done: 255 IP addresses (8 hosts up) scanned in 4.82 seconds
 
In nping's case you might want a similar summary line on a per-proto basis.
 
M4) -p should give an error if non-TCP/UDP modes are used, if I understand
your options (e.g. ³nping -p 80 -c 1 --icmp 192.168.0.1²).
 
M5) I had to laugh when I saw "Note that, for technical reasons, a
passphrase still needs to be supplied after the --echo-client or
--echo-server flags, even though it will be ignored." I didn¹t realize
programmer laziness was a technical reason ;)  Why not just flag an error if
you use ­nc and they try to send a password as well?
 
M6)  The --bpf-filter option is just weird.  Just sayin ;)   But to extend
the ideaŠ what would rock if you could attach nping/npacket/ncapture to a
process and watch the packets going to and fro to whatever is talking to
that, that would rule.  Heck, also have the ability to filter packets on the
fly while I¹m dreaming.
 
M7) just remove summary with ­N option, it¹s useless.
 
M8)   The man page is longŠ but you really should have some examples of
setting fields/payloads.
 
If this was really a packet construction kit... well, if you could output
packets sent/received to filesŠ then you could also have a way to resend
them, useful for testingŠ maybe even read/write pcap there.   I'd even take
a packet configuration file, where I could specify all the options in the
file and you'd just suck it up and do the right thingŠ. Either via variables
or just raw bits ala the tables in http://en.wikipedia.org/wiki/IPv4
<http://en.wikipedia.org/wiki/IPv4> .   To abuse an analogy you could split
up the pieces, and have things like body and header files(sic!) that could
be sucked up by the various nping options.   Change the name to npacket!
 
M9)  You really, really, really need a way to generate output that is
parseable.   Throw me some XML/JSON bones, or at least CSVŠ reuse that nmap
code!
 


^..^


Attachment: nping notes 4 dev.docx
Description:

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]