Re: Some general questions about Nping/Ncat

["Luis MartinGarcia." <luis.mgarc () gmail com>]

Hi David,

Thanks for reporting all those problems. I comment on each Nping-related
issue below:


On 09/30/2011 03:38 AM, David Lam wrote:
> Hello all.
> Just a few questions about Nping/Ncat (v.0.5.61TEST1), would appreciate it
> someone can give me some insights into this.
>
> 1) It seems like Nping is having a hard time determining the adapter to use
> when one is on a static IP address (not assigned by DHCP). When Nping is
> run, it will report:
> Device used for target host x.x.x.x seems to be down.
> In addition, when more than one default gateways are available (e.g. LAN and
> WLAN), sometimes Nping will get the adapters mixed up (e.g. it will send
> packets out on the WLAN interface with the LAN's assigned IP address, rather
> than sending packets out the LAN interface with the LAN's assigned IP
> address.)

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"


> 2) When using Nping to do a trace route (using --tr), is it possible to have
> Nping resolve the IP addresses just like a normal trace route would?
> I am currently using this command: nping --tcp -tr 4.2.2.1 -p 53 -delay 50ms
> -H

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.


> In addition, in TCP traceroute mode, would it be possible to ask Nping to
> stop once it gets an SYN-ACK response back from the destination host rather
> than continuously hitting the host until the max TTL?

Currently you can't but I'll add a to-do item for this.

> 3) For ARP pings (nping --arp 192.168.0.1), RTT times are reported as N/A.
> Is this intended?

This is also a known issue that is already in Nping's to-do list.

> 4) Nping's broadcast ping doesn't seem to work (maybe it is related to issue
> #1 I am having?) I can see the echo request go out and a lot of echo replies
> coming back in, but Nping isn't registering any of them (nping 192.168.0.255
> --dest-mac ff:ff:ff:ff:ff:ff -c 1).
> When broadcast pings did work (I believe it was in an earlier version), 

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.


> When broadcast pings did work (I believe it was in an earlier version), I
> remember that it outputted a lot of statistics that were appended on the
> bottom. Is there a way to turn this off?

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.


> Also, would it be at all possible to ping 224.0.0.1 from a Windows
> prespective?

Same thing. As 224.0.0.1 is an official multicast address, Nping will
not know how to deal with incoming packets whose source address is not
the same address as the sent probe.


> 5) Nping does not respect the --ws switch (nothing happens), which allows
> the Windows Scaling to be set. Is this only intended for Linux systems or is
> this no longer in use? (e.g. I can set the windows size to 1000 using --win
> 1000, but --win 1000 and --ws 8 also results in a TCP window size of 1000.
> The correct window scaling factor was not reported in the outbound SYN
> packet).

You are right. Nping does not currently support TCP options. We already
have a TO-DO item for it.


> 7) Would it also be possible to include Data payloads in Nping's generated
> packets in ways that could solicit a reply (e.g. UDP DNS requests or BOOTP
> requests)? If so, how?

This is also a feature we have in the to-do list. The plan is to make
Nping and Nmap share the UDP payloads code. However, until we implement
it, you can append any payload you want. Check the section "PAYLOADS" in
Nping's man page.


I am not sure I'll be able to implement all the things mentioned above
but I'll try to work on at least some of them in the next few weeks.

Regards,

Luis MartinGarcia.


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