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/
Current thread:
- nping notes dan farmer (Apr 14)
- Re: nping notes Djalal Harouni (Apr 15)