Re: Some general questions about Nping/Ncat

[David Lam <david () thedavid net>]

1) Does it work well when you specify an interface name explicitly with the
-e switch? In which OS do you experience that behavior? Windows? Could
you please run it with -d6 and send the output you get. Also, please
include the ouput of "nmap --iflist"

I have actually tried this before, but it doesn't work - looking at the
--iflist more closely, it appears there is a mismatch between the listed
interfaces and the listed routes. That may explain the inconsistency with
how Nping was listening or sending packets.

Under Interfaces (redacted):
eth1 (eth1)  169.23X.XXX.168/24                    ethernet    up   1300
5C:26:0A:XX:XX:XX

Under routes (redacted):
0.0.0.0/0                             eth0 169.23X.XXX.254

As you can see, eth1's gateway is 169.23X.XXX.254, and this was showing up
as eth0 in the routes.

Since the gateway was not established using DHCP, doing a route print in
Windows lists the gateway as a static route like this:

"===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0   169.23X.XXX.254  Default
==========================================================================="

2) I guess you mean reverse DNS resolution. This is a known issue. Here's
what we have in Nping's to-do list:

* Decide more on rDNS
 - Do we want to rDNS resolve all target IPs?  If so, where should we
  show the name?  At the final report (even when just one host
  scanned, which omits that line now)?  In the individual packet
  trace lines?  When a CNAME (or a name which forward resolves but
  does the IP doesn't reverse resolve) is specified on the command
  line, should we use that version, or the official rDNS, if any?
 - Some more discussion on this topic on nmap-dev may be warranted.

The thing is that implementing rDNS in Nping is not straighforward. In
nmap it's a bit easier because it does not print anything until it
finishes so it can do rDNS at any point. In Nping we'd have to resolve
the name asynchronously in parallel with the packets being sent and
captured from the wire. How do you picture reverse DNS resolution in
Nping? How would you like the output to be? If you come up with a
proposal, I'll consider investing some time implementing it.


I see what you are saying. This is why I assume this would only be done when
the --tr switch is used. (I assume if rDNS is implemented, people can turn
this off with -n)
That being said, I would expect that if a user were to do a UDP traceroute
on port 53 to their DNS server that Nping would also place its rDNS probes
in its results too. (If you want to be specific, maybe add an switch to
filter those out too, but I don't really think it's necessary.)

Ideally, when --tr is run, the output SHOULD look like output for a
traceroute. (e.g. No -H needed to hide SENT probes, since in a traceroute
you are probably not interested in what's being sent anyways)
Suppose I run the following: nping --tcp --tr 4.2.2.1 -p 53
It would be nice to have a clean output similar to the following (-v for
more verbosity? TCP source ports, dst ports, len, id, etc...):
1. 192.168.0.1 (192.168.0.1) - (TTL: 1, TCP: S RTT: 0.83 ms)
2. routing.xyzcompany.com (192.168.0.254) - (TTL: 2, TCP: S,  RTT: 1.34 ms)
3. link22-ab.linkme.com (91.88.13.19) - (TTL: 3, TCP: S, RTT: 3.98 ms)
4. dmz.abcd.company.com (81.13.66.18) - (TTL: 4, TCP: S, RTT: 8.30 ms)
5. dns.public.blah.com (4.2.2.1) - (TTL: 5, TCP: SA, RTT: 11.34 ms)

It would also be nice if Nping has a mode for averaging RTT times, although
not a really big thing for me right now.

3) Are you sure the broadcast ping worked in an earlier version. I don't
think it did. I haven't looked into this but I'm pretty sure the packets
are not being captured because the BPF filter only accepts packets
coming from 192.168.0.255 because I didn't consider the possibility of
broadcast pings when I implemented that. However, I think we should
support that feature so I've added it to the to-do list as well.
Do you mean turn off the statistics? Currently there is no way to do
that. There is the -q option, which decreases the verbosity level by one
unit but it probably does not do what you expect. Is that feature
something important for you? It should be easy to add a switch to the
command line to prevent the stats from being displayed. If you think
it's worth, I'll consider implementing it.

Come to think of it, I believe I actually did/meant this instead:
nping --arp 192.168.0.1-254 -c 1 --delay 50ms -H
However, as you can see, doing this will generate a lot of statistics on the
bottom which is not what I am trying to look for anyways.
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/