Nmap Development mailing list archives
Re: Some general questions about Nping/Ncat
From: David Lam <david () thedavid net>
Date: Fri, 30 Sep 2011 15:16:46 -0700
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/
Current thread:
- Some general questions about Nping/Ncat David Lam (Sep 29)
- Re: Some general questions about Nping/Ncat Luis MartinGarcia. (Sep 30)
- Re: Some general questions about Nping/Ncat David Lam (Sep 30)
- Re: Some general questions about Nping/Ncat David Fifield (Sep 30)
- Re: Some general questions about Nping/Ncat David Lam (Sep 30)
- Re: Some general questions about Nping/Ncat Luis MartinGarcia. (Sep 30)